Testing

Playwright88.2k★

Playwright is the best browser automation tool right now, covering Chrome, Firefox, and Safari/WebKit for testing, scraping, screenshotting, and PDF generation. It gives you a single API to control all three browser engines with auto-waiting, parallel execution, and a built-in test runner. Apache 2.0, built by Microsoft (the team that originally created Puppeteer at Google). Playwright fixed Puppeteer's biggest limitations: it supports all browsers, has smarter auto-waiting so tests are less flaky, includes codegen (record your clicks and it writes the test), and runs tests in parallel by default. Everything is free. No paid tier. Microsoft doesn't monetize Playwright directly. It drives adoption of Azure DevOps and GitHub Actions. The catch: Playwright downloads all three browser engines (~400MB) on install, which can be slow and frustrating in CI. The API surface is huge. It does everything, which means more docs to read. And while the test runner is excellent, migrating an existing Cypress or Selenium test suite takes real effort. If your tests are already working in Cypress and you're happy, switching has a cost.

Cypress49.6k★

Cypress runs end-to-end tests in a real browser with a UI that shows you each step as it happens. No Selenium, no driver headaches. You write JavaScript, it clicks things, you watch it happen live. MIT licensed. The open source version gives you a full test runner, time-travel debugging (step backward through your test), automatic waiting, and screenshot/video capture on failure. That's enough for most solo devs and small teams. Cypress Cloud is where the money comes from. $67/mo for up to 500 test results, scaling to $250/mo and beyond. Cloud gives you parallelization across machines, flake detection, test analytics, and a dashboard to track trends. The parallelization alone can cut a 60-minute suite to 10 minutes. Solo or small team: free tier handles it. Once your test suite grows past 500 runs per month or you need CI parallelization, you're paying. At $67/mo for a small team, that's reasonable. A flaky test suite wastes more engineering hours than that. The catch: Cypress only tests what runs in a browser. No native mobile, no multi-tab testing. And the free tier's 500 test results per month disappears fast with any real CI pipeline.

Jest45.3k★

It's the default testing framework for React, and most JavaScript projects use it whether they chose it or not: Create React App, Next.js, and dozens of starter templates include it. Jest bundles everything: test runner, assertion library, mocking, code coverage, and snapshot testing. You don't need to wire together Mocha + Chai + Sinon + Istanbul; Jest includes all of it. Write a file ending in `.test.js`, run `jest`, and it finds and runs your tests automatically. Snapshot testing is Jest's signature feature. Render a component, Jest saves the output. Next run, it compares. If something changed, the test fails and shows you the diff. Great for catching unintended UI changes. The catch: Jest is showing its age. It's slow compared to Vitest, which uses Vite's transform pipeline and runs significantly faster on modern projects. Jest's config can be painful, especially with ESM modules, TypeScript transforms, and custom module resolution. The project's development pace has slowed since Meta reduced its open source investment. For new projects in 2026, Vitest is the better choice. For existing projects with thousands of Jest tests, the migration cost probably isn't worth it yet.

Selenium34.1k★

Selenium is the browser automation tool that started it all: clicking buttons, filling forms, scraping pages, running tests. It drives real browsers (Chrome, Firefox, Safari, Edge) programmatically, and it works with practically every programming language: Java, Python, C#, Ruby, JavaScript. Selenium WebDriver talks directly to browser engines through standardized protocols. Write a test in Python, it opens Chrome, navigates to your app, clicks through your checkout flow, and tells you if something broke. The WebDriver protocol it pioneered is now a W3C standard that every browser implements. Selenium Grid lets you run tests in parallel across multiple browsers and machines. For CI pipelines testing against Chrome, Firefox, and Safari simultaneously, Grid is the standard approach. The catch: Selenium feels its age. Setup is fiddly: you need browser drivers that match your browser versions, and version mismatches cause cryptic errors. Tests are slower than modern alternatives because they drive full browsers through an HTTP protocol. Flaky tests are a known pain point. Playwright (from Microsoft) does everything Selenium does with better auto-waiting, built-in browser management, and faster execution. If you're starting fresh, Playwright or Cypress are better choices. Selenium's advantage is ecosystem size and language support: if you're in Java or C#, the alternatives are thinner.

k630.5k★

K6 lets you write those load tests in JavaScript and run them from the command line. No JMeter XML, no clunky GUI. You write a script, run `k6 run script.js`, and get performance metrics back in seconds. Go, AGPL v3 (important, more on that below). Grafana acquired k6 in 2021. The CLI is fast, resource-efficient, and scriptable. You can test HTTP, WebSocket, gRPC, and browser-level interactions. Results integrate natively with Grafana dashboards, Prometheus, Datadog, and most observability stacks. The CLI is free and always will be. Write tests, run them locally, pipe results wherever you want. No limits on virtual users or test duration when self-hosted. Grafana Cloud k6 is the paid option: starts at $0 for limited cloud runs (50 cloud tests/month on the free plan), then scales with usage. Cloud gives you distributed load generation from multiple regions, something the local CLI can't do alone. Solo and small teams: the CLI is all you need. Run tests from your CI pipeline, export to Grafana. Medium teams: cloud makes sense when you need to simulate traffic from multiple geographic locations. Large teams: Grafana Cloud k6 or self-host the execution infrastructure. The catch: the AGPL license means if you modify k6 and offer it as a service, you must open source your changes. For running tests internally this doesn't matter. But if you're building a testing platform on top of k6, talk to a lawyer first.

Locust27.8k★

Define user behavior as Python code, point Locust at your endpoint, and scale up to millions of simulated users. The web UI shows real-time results: requests per second, response times, failure rates. The reason developers love this: it's just Python. No special syntax, no config files, no learning a testing DSL. If you can write a Python function, you can write a load test. Need to test a complex multi-step flow with authentication? It's just Python code. MIT. Fully free. No paid tier, no cloud service. The homepage links to PyPI, not a commercial product. The catch: Locust is CPU-bound because of Python's GIL. For high-throughput testing (10K+ requests/sec), you need to run distributed across multiple workers. Tools like k6 (Go-based) handle higher throughput per instance. Also, the web UI is functional but basic. If you want fancy dashboards, you'll need to export metrics to Grafana.

React Testing Library19.6k★

React Testing Library forces you to test your components the way users interact with them: clicking buttons, filling forms, reading text on screen. Instead of testing implementation details (state, props, lifecycle), you test what the user sees and does. MIT licensed, created by Kent C. Dodds. This is the default testing approach for React. Create React App ships with it. The React docs recommend it. Most React job postings expect you to know it. Fully free. It's an npm package. No paid tier, no service. The catch: the philosophy is opinionated and that's the point. You can't easily test internal component state or mock child components, by design. If you're coming from Enzyme, the transition is a mindset shift. Some complex UI interactions (drag-and-drop, canvas, virtual scrolling) are hard to test with this approach. And for end-to-end testing (real browser, real clicks), you still need Playwright or Cypress. React Testing Library runs in jsdom, not a real browser.

Vitest16.5k★

Vitest is the testing framework that makes Jest feel like last decade. Same familiar API (`describe`, `it`, `expect`) but instant startup, native TypeScript support, and hot module reloading for your tests. What's free: Everything. MIT license. The entire testing framework, all matchers, mocking, coverage, UI mode, browser mode. All free. Vitest's speed comes from Vite's transformation pipeline. No separate TypeScript compilation step, no Babel config, no jest.config.js with 40 lines of transform rules. Point it at your code and it works. The compatibility with Jest's API means migrating is often just changing imports. The `, ui` mode gives you a browser-based test explorer that's useful. The catch: if you're not in the Vite ecosystem, some of the speed advantages diminish. The browser testing mode is still maturing. And while the Jest API compatibility is high, it's not 100%. Some Jest plugins and custom matchers need adaptation. For non-Vite projects with heavy Jest customization, the migration cost might not be worth it.

MailHog16.0k★

MailHog catches all outgoing email from your development environment and displays it in a web UI instead of actually delivering it. Point your app's SMTP at localhost:1025, and every email lands in MailHog instead of going anywhere. It's a fake mailbox for development. MIT license, Go. Single binary, zero configuration. Start it, configure your app's SMTP to point at it, done. The web UI at port 8025 shows every email with headers, body, HTML rendering, and attachments. Has a JSON API for automated testing: verify emails were sent in your CI pipeline. Fully free. No paid tier, nothing to pay for. It's a development tool, not a production service. Every developer who builds email-sending features: use this. Solo to enterprise, the setup is identical: `docker run mailhog/mailhog` or download the binary. Takes 30 seconds. The catch: MailHog is essentially unmaintained. The last commit was years ago. It works fine for basic SMTP testing, but don't expect updates or new features. For a maintained alternative, Mailpit is a drop-in replacement that's actively developed. Also, MailHog is development-only. Never expose it to the internet, there's no authentication on the web UI.

Pytest13.8k★

Pytest is the Python test framework that makes writing tests feel natural. Pytest is the one. It's what the Python community converged on, and for good reason: you write plain functions with assert statements, and pytest figures out the rest. No boilerplate classes, no self.assertEqual nonsense. Write `def test_something:`, use a normal `assert`, and pytest gives you rich failure output showing exactly what went wrong. The fixture system is powerful: dependency injection for tests that keeps setup clean. The plugin ecosystem (1,000+ plugins) covers everything from parallel execution to coverage to Django integration. Completely free. MIT license. No paid tier, no hosted version. Just `pip install pytest`. Every Python developer should use this. Solo, team of 5, team of 500, it scales. The fixture system actually gets MORE useful as your test suite grows because you can share setup across modules without inheritance hierarchies. The catch: fixtures have a learning curve. Scope, autouse, and parameterization can get confusing fast. And if you're coming from unittest, the magic can feel uncomfortable at first.

pydoll6.8k★

Pydoll controls Chromium browsers using the Chrome DevTools Protocol directly, without needing a WebDriver binary like Selenium does. The pitch: faster startup, lower overhead, no driver version mismatches. MIT license, Python. It's async-first (built on asyncio), which means you can control multiple browser tabs concurrently without threading. Supports page navigation, screenshots, PDF generation, network interception, and cookie management. Fully free. No paid tier, no hosted version. Pure Python library. The honest take: Pydoll is the new kid in a crowded space. At and growing, there's clear interest, but Playwright (by Microsoft) has a far larger community, better documentation, and handles Firefox and WebKit in addition to Chromium. Pydoll's advantage is simplicity. It's a lighter abstraction if you specifically want CDP control without Playwright's full framework. Solo developers experimenting with browser automation: try it, the API is clean. Teams building production scrapers or test suites: Playwright is the safer bet for now. The catch: Chromium-only. No Firefox, no Safari/WebKit. The documentation is early-stage. And 'no WebDriver needed' sounds great until you realize Playwright also doesn't need a separate WebDriver and supports three browser engines. Pydoll needs to find a stronger differentiator as it matures.

bombadil1.2k★

Bombadil autonomously explores your UI and validates correctness properties. It's property-based testing applied to web UIs: you define what 'correct' means and it finds every way your app violates that. Unlike traditional end-to-end tests where you script specific paths, Bombadil explores paths you didn't think of. It clicks, types, navigates, and checks invariants at every step. When it finds a violation, it gives you the exact sequence of actions that broke it. early but. MIT licensed, Rust. The catch: property-based testing requires you to define properties: 'no console errors,' 'this element always exists,' 'this form never submits empty.' Writing good properties is a skill, and bad properties produce either false positives or miss real bugs. And autonomous exploration of complex UIs can be slow. A full exploration of a large app takes real time.

kumo1.1k★

Kumo is a single-binary AWS service emulator written in Go. It mocks 76 AWS services (S3, DynamoDB, Lambda, SQS, KMS, IAM) for local development and CI testing. No authentication required, AWS SDK v2 compatible, optional persistence. The pitch is LocalStack with less weight and no Docker dependency. Setup is downloading a binary or running a container. Point your AWS SDK at the local endpoint and you get an emulator that does not ask for credentials. CI integration is straightforward because there is no auth dance and the binary boots fast. Set `KUMO_DATA_DIR` to keep state across restarts. Solo developers: use it for CI tests and local dev without an AWS sandbox account. Small and mid-sized teams: a free way to keep AWS-dependent tests fast and predictable. Large teams: LocalStack Pro is still ahead on coverage breadth and edge case fidelity, so this is more of a niche pick than a wholesale replacement. The catch: 76 services sounds like a lot, but coverage depth varies. Kumo is solid for the common cases (S3, DynamoDB, SQS) and weaker on niche APIs. Verify your specific use case before committing.