Playwright
Playwright has become the gold standard for browser automation. Released by Microsoft in 2020, it quickly surpassed Selenium and gave Cypress serious competition, offering faster test execution, better support for modern web patterns (shadow DOM, iframes, async operations), and a genuinely excellent developer experience. There's one problem: Playwright
Testing
Playwright is a strong choice for smoke testing. It's fast, handles modern web apps well, and has built-in support for parallel execution, auth state persistence, and multiple browsers. This post walks through building a complete smoke test suite with Playwright, from project setup to CI integration. Project Setup
Test Reliability
Flaky tests cost CI time and erode confidence. Playwright gives you several tools to manage flakiness: automatic retries that reduce false negatives, --repeat-each for detecting flakiness before it hits CI, and test.fail() for acknowledging known issues without deleting coverage. This post covers all three strategies — when to use each,
Testing
End-to-end tests are slow by nature — they launch browsers, navigate real pages, wait for network. A 400-test Playwright suite can take 20-30 minutes on a single runner. Sharding splits those tests across multiple workers and brings that down to 5-8 minutes. Here's how to configure it on GitHub
Testing
Test results buried in terminal output are nearly useless for teams. Allure Report transforms your Playwright test results into interactive HTML dashboards with screenshots, video attachments, execution history, and trend charts. Here's how to set it up. Why Allure with Playwright Playwright's built-in HTML reporter is
Testing
Playwright generates a rich interactive HTML report — but it only exists locally after a test run. Pushing it to GitHub Pages gives your team a permanent, browsable URL for every test run without spinning up any infrastructure. Here's the complete setup. What You Get After following this guide:
Testing
Both Storybook and Playwright can test UI components in a real browser. Both give you real DOM interaction, real CSS, and real browser behavior. But they approach component testing from different angles, and choosing the right one (or combining both) depends on your priorities. This guide compares Storybook and Playwright
Accessibility Testing
Most teams integrate @axe-core/playwright and call it done. You get a scan, you fix the violations, you ship. But axe-core catches maybe 30–40% of real accessibility issues. The rest — focus management failures, broken ARIA live regions, keyboard traps, flawed reading order — require behavioral testing that axe can'
Testing
Argos CI is a visual testing platform that compares screenshots between your main branch and pull requests. When a PR changes the visual appearance of a component or page, Argos shows the before/after diff in GitHub and can block the PR until a team member approves the change. It
Testing
GrowthBook is an open-source A/B testing and feature flag platform with a JavaScript SDK that works in both Node.js and browsers. This tutorial covers SDK setup, writing Jest unit tests for flag evaluation, Playwright tests for UI experiment variants, and setting up GrowthBook in CI without a live
Testing
Playwright can automate the browser half of email flows—fill out forms, trigger emails—but it can't read inboxes. Connecting Playwright to IMAP lets you complete the loop: trigger an action in the browser, wait for the email to arrive via IMAP, extract the OTP or link, then
Testing
Payment flows are among the most critical user journeys in any application. A broken checkout means lost revenue; a broken refund flow means customer support calls. End-to-end payment testing validates the complete flow from clicking "Buy" through webhook processing and database updates. This guide covers E2E payment testing