Build a practical screenshot-based visual regression workflow for pull requests, previews, and production releases.
If your screenshot API keeps returning a 'Checking your browser' page instead of the site, the target is behind bot protection. Here's how to capture it with stealth mode.
TutorialSet up an automated check that screenshots a competitor's pricing page on a schedule and emails you only when it actually changes. Point-and-click setup, about five minutes.
Developers, marketers, and founders use Allscreenshots to automate website captures. No credit card required to get started.
Playwright is a browser automation framework built for end-to-end testing. It lets you drive Chromium, Firefox, and WebKit with one API, write assertions against real pages, and debug failures with traces, videos, screenshots, and a visual test runner.
The reason teams adopt Playwright is not that it can click buttons. Selenium, Cypress, Puppeteer, and browser drivers can all do that. The reason is reliability: Playwright waits for elements to be actionable, isolates tests in fresh browser contexts, and gives you enough tooling to understand failures quickly.
This guide covers the practical pieces you need for a maintainable Playwright suite.
Playwright is strongest when you need to verify complete user journeys:
It is less useful for pure unit testing. If you only need to verify a helper function, use a unit test runner. If you need to verify that a user can complete a workflow in a real browser, use Playwright.
For a Node.js project, start with:
npm init playwright@latestThe installer creates a config file, example tests, and browser setup. Run the suite with:
npx playwright testOpen the HTML report after a run:
npx playwright show-reportA minimal test looks like this:
const { test, expect } = require('@playwright/test');
test('visitor can open the pricing page', async ({ page }) => {
await page.goto('https://example.com/pricing');
await expect(page.getByRole('heading', { name: /pricing/i })).toBeVisible();
});The important detail is the assertion. End-to-end tests should prove something meaningful about the page, not just open a URL.
Most flaky browser tests fail because the test acts before the page is ready. Playwright avoids a lot of that with actionability checks.
Before clicking, Playwright checks that the target is:
That means this line already includes waiting behavior:
await page.getByRole('button', { name: 'Create account' }).click();You usually do not need:
await page.waitForTimeout(3000);Fixed sleeps make tests slower when the app is fast and unreliable when the app is slow. Prefer locators, web assertions, and app-specific readiness signals.
If a test needs a wait, wait for something the user would recognize: a heading, button, URL, dialog, toast, table row, or loaded state. Avoid waiting for arbitrary time.
Playwright's locator API encourages selectors based on what users see and assistive technologies understand.
await page.getByRole('button', { name: 'Save changes' }).click();
await page.getByLabel('Email address').fill('[email protected]');
await page.getByPlaceholder('Search projects').fill('billing');
await page.getByText('No invoices found').isVisible();Role and label locators make tests more resilient than brittle CSS chains:
// Fragile: depends on implementation and styling
await page.locator('.modal .footer .btn.primary').click();
// Better: describes the user-facing control
await page.getByRole('button', { name: 'Confirm' }).click();Use getByTestId when the UI text is not stable or when you need to target a technical state:
await page.getByTestId('billing-plan-pro').click();Avoid selectors built from generated class names. CSS modules, Tailwind build output, design system updates, and refactors can break those tests even when the user experience is unchanged.
A good Playwright test reads like a workflow:
const { test, expect } = require('@playwright/test');
test('user can create a project', async ({ page }) => {
await page.goto('https://app.example.com/projects');
await page.getByRole('button', { name: 'New project' }).click();
await page.getByLabel('Project name').fill('Website redesign');
await page.getByRole('button', { name: 'Create project' }).click();
await expect(page).toHaveURL(/projects\/[a-z0-9-]+/);
await expect(page.getByRole('heading', { name: 'Website redesign' })).toBeVisible();
await expect(page.getByText('Project created')).toBeVisible();
});Notice what the test does not assert:
End-to-end tests are expensive compared with unit tests. Spend them on paths that matter.
Logging in through the UI before every test is slow and can make unrelated tests fail when the login page changes.
Use Playwright's storage state feature to authenticate once and reuse the session:
// tests/auth.setup.js
const { test: setup, expect } = require('@playwright/test');
setup('authenticate', async ({ page }) => {
await page.goto('https://app.example.com/login');
await page.getByLabel('Email').fill(process.env.TEST_USER_EMAIL);
await page.getByLabel('Password').fill(process.env.TEST_USER_PASSWORD);
await page.getByRole('button', { name: 'Sign in' }).click();
await expect(page.getByRole('heading', { name: 'Dashboard' })).toBeVisible();
await page.context().storageState({ path: 'playwright/.auth/user.json' });
});Then reference it in config:
module.exports = {
projects: [
{ name: 'setup', testMatch: /.*\.setup\.js/ },
{
name: 'chromium',
use: { storageState: 'playwright/.auth/user.json' },
dependencies: ['setup']
}
]
};This keeps product-flow tests focused on the product flow, not on repeated login mechanics.
Playwright can run the same test suite against multiple browser engines.
const { devices } = require('@playwright/test');
module.exports = {
projects: [
{ name: 'chromium', use: { browserName: 'chromium' } },
{ name: 'firefox', use: { browserName: 'firefox' } },
{ name: 'webkit', use: { browserName: 'webkit' } },
{
name: 'mobile-chrome',
use: { ...devices['Pixel 7'] }
},
{
name: 'mobile-safari',
use: { ...devices['iPhone 14'] }
}
]
};You do not need every browser on every test at first. A practical setup is:
This gives broad coverage without turning every pull request into a slow browser matrix.
End-to-end tests should exercise real integrations where that matters. But for flows dominated by volatile APIs, network mocking can reduce noise.
test('shows the empty invoice state', async ({ page }) => {
await page.route('**/api/invoices', async (route) => {
await route.fulfill({
status: 200,
contentType: 'application/json',
body: JSON.stringify({ invoices: [] })
});
});
await page.goto('https://app.example.com/billing');
await expect(page.getByText('No invoices yet')).toBeVisible();
});Use mocks for:
Keep at least a few smoke tests wired to real backend paths so the suite still catches integration issues.
Playwright traces are one of its best features. Configure traces for retries:
module.exports = {
retries: process.env.CI ? 2 : 0,
use: {
trace: 'on-first-retry',
screenshot: 'only-on-failure',
video: 'retain-on-failure'
}
};Open a trace with:
npx playwright show-trace trace.zipThe trace viewer shows DOM snapshots, console logs, network requests, screenshots, timing, and each Playwright action. Instead of guessing why CI failed, you can inspect what the browser saw.
For local debugging:
npx playwright test --ui
npx playwright test --debug
npx playwright test --headedUI mode is useful for exploring failures and rerunning a single test while you edit.
A basic GitHub Actions workflow:
name: Playwright
on:
pull_request:
push:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test
- uses: actions/upload-artifact@v4
if: failure()
with:
name: playwright-report
path: playwright-report/For faster CI, cache dependencies, split large suites into shards, and run browser projects selectively.
npx playwright test --shard=1/4
npx playwright test --shard=2/4
npx playwright test --shard=3/4
npx playwright test --shard=4/4Playwright can take screenshots:
await page.screenshot({ path: 'dashboard.png', fullPage: true });That is useful inside a test, especially for failure artifacts. But screenshot-heavy workflows often need more than a local browser call:
For those cases, use AllScreenshots screenshot automation alongside Playwright:
const response = await fetch('https://api.allscreenshots.com/v1/screenshot', {
method: 'POST',
headers: {
Authorization: `Bearer ${process.env.SCREENSHOT_API_KEY}`,
'Content-Type': 'application/json'
},
body: JSON.stringify({
url: 'https://example.com',
fullPage: true,
viewport: { width: 1440, height: 900 },
format: 'png'
})
});Use Playwright to prove behavior. Use AllScreenshots for repeatable screenshot capture, visual regression testing, scheduled screenshots, and documentation workflows.
| Need | Recommendation |
|---|---|
| Test a real user journey | Playwright |
| Verify cross-browser behavior | Playwright |
| Unit test business logic | Unit test runner |
| Capture many URLs on a schedule | Screenshot API |
| Generate visual baselines | Playwright or Screenshot API |
| Monitor production pages visually | Website monitoring |
Playwright is a strong default for end-to-end testing because it balances realistic browser coverage with practical developer tooling.
Playwright gives teams a reliable way to test modern web applications in real browsers. Start with a few critical user flows, use locators that match user intent, avoid fixed waits, capture traces in CI, and expand browser coverage as the suite proves its value.
For screenshot-specific workloads, pair it with AllScreenshots so your test suite does not become a screenshot infrastructure project.