Smart Contract Testing
Most Web3 testing guides cover smart contract unit tests or frontend component tests in isolation. But users experience your dApp end-to-end: they connect a wallet, click a button, wait for a transaction, and see the updated state. If any part of that chain breaks, they lose money or
Testing
End-to-end testing a serverless architecture is fundamentally different from testing a traditional server. Your "application" is a graph of functions, queues, databases, and managed services. A user action might trigger five Lambda functions sequentially, write to DynamoDB, publish to SQS, and fire a webhook — all before
Selenium
The question comes up constantly in teams that are modernizing their test automation stack: should we invest in Selenium Grid infrastructure, or switch to Playwright and use its built-in parallel execution? The answer isn't as obvious as Playwright advocates would have you believe. Both approaches solve the
Testing
End-to-end tests for micro-frontends are harder to set up than for monolithic apps, but they're not optional. Unit tests and contract tests verify pieces in isolation. E2E tests verify that everything works together when a real user navigates through the composed application — crossing remote boundaries,
playwright
Component tests that hit real APIs are integration tests wearing a costume.
Puppeteer
Puppeteer and Playwright share a common origin — most of Playwright's founding team came from the Puppeteer project at Google. They look similar at first glance, but they've diverged significantly. Choosing the wrong one adds friction to your testing workflow. This is a practical comparison covering what
playwright
Playwright's built-in screenshot comparison is a pixel differ with a configurable threshold. It works well out of the box, but the default failure output — a saved PNG diff in your test results directory — is awkward to review. Developers end up running tests locally, opening three images side
Performance Testing
Lighthouse is good at measuring page load performance. It's bad at measuring everything that happens after load: navigation between pages, complex interactions, data-heavy operations, application-specific flows. For those, Playwright with Chrome DevTools Protocol (CDP) is the right tool. This guide covers using Playwright to catch performance
Testing
Testing multilingual applications is one of those things teams either do well or skip entirely. When you skip it, you find out the hard way: a Japanese user reports that your checkout button disappears, a German customer can't read dates, or your Arabic support launch breaks the entire
playwright
@playwright/experimental-ct-svelte brings the same mount-in-browser approach to Svelte that the React and Vue adapters provide. The component runs in a real browser, in a real DOM, with real Svelte reactivity — not a jsdom approximation. For Svelte specifically, this matters because Svelte's compiled output
playwright
Playwright Component Testing (CT) runs your components inside a real browser, mounted in an iframe served by a Vite dev server. That's the key detail that explains why React Server Components cause problems: RSC requires a Node.js runtime to execute, and there is no Node.js inside
playwright
Playwright Component Testing has a startup cost that unit test frameworks don't: each worker spins up its own Vite dev server. With 2 workers, you have 2 Vite instances. With 8, you have 8. At small scale this is invisible. At 500+ component tests across a large design