arrow-left Back to topicQuizLibraryCheck yourself1.You write a Node.js script that scrapes product prices from a competitor's website every night. Which Playwright package should you use?@playwright/test — it works for scripts tooplaywright (the library) — this is an automation script, not a test suite, so the library's manual control is appropriateNeither — use Puppeteer for scrapingplaywright-core — the minimal package without browser binaries2.In a library script, you create a browser and context, run your code, but forget to call context.close() and browser.close(). What happens?Playwright automatically closes the browser when the Node.js process exitsThe browser process keeps running as a zombie process — consuming memory and file descriptors until the OS kills itThe browser closes after 30 seconds of inactivityNode.js throws an unhandled rejection error on process exit3.In a library script you use console.assert(title === 'Example'). In @playwright/test you use await expect(page).toHaveTitle('Example'). What's the key behavioral difference?console.assert throws an error; expect().toHaveTitle() logs a warningexpect().toHaveTitle() auto-retries — if the page title isn't ready yet it keeps checking until timeout; console.assert checks once and either passes or fails immediatelyOnly the format of the error message is different — both check the condition onceconsole.assert works synchronously; toHaveTitle is async only because of the await keyword4.You're building a browser automation tool for your team — not a test suite, but a tool that automates repetitive browser workflows. Which package is more appropriate?@playwright/test — the test runner provides useful infrastructureplaywright (library) — automation tools, scripts, and non-test browser work are the library's primary use caseEither is fine — they have identical APIs for browser controlplaywright-core — it has the lowest overhead for production automation tools5.What does @playwright/test add on top of the playwright library that you'd have to build yourself with the library?The browser API — page.click(), page.goto(), locatorsTest isolation (fresh page/context per test), web-first assertions, retries, parallel workers, fixture system, reporters, and automatic cleanupTypeScript support — the library only works with JavaScriptMulti-browser support — the library can only use Chromium6.In the library, you call chromium.launch() without any options. What type of browser does this start?The system-installed Chrome browserA headless Chromium browser — no visible window, optimized for automationA headful Chromium browser with a visible windowIt depends on the operating system — macOS uses Safari, Linux uses headless Chromium7.How do you install the playwright library (not the test runner) and its browsers?npm init playwright@latest — the same setup command as the test runnernpm install playwright, then npx playwright install — install the package then download browser binaries separatelynpm install playwright-chromium — a dedicated package that includes the browsernpm install playwright — browsers are bundled and installed automatically8.A colleague suggests using @playwright/test for your automation script because 'the test runner has better error messages'. Is this a good reason?Yes — better error messages alone justify using the test runner for any browser automationPartially — web-first assertions do have better error messages, but they come with test runner overhead. If the script genuinely benefits from assertions like toBeVisible(), it may be worth using @playwright/testNo — error messages are identical between library and test runnerNo — the library has all the same assertion utilities through the expect APISubmit answersarrow-left PreviousBrowsersAgentsNext arrow-right