Components to write, run and evaluate tests with Claude Code.
In a codebase without tests, every change forces you to check by hand what already worked. The problem usually shows up when the team grows or when an old fix breaks again. Automated tests are the net that catches those regressions before the user does, but writing them is slow work: you have to understand the code, come up with edge cases, prepare test data and keep all of it alive as the project changes.
The components on this page hand part of that work to Claude Code. Some read a source file and return the matching test file, with mocks and edge cases already thought through. Others analyze existing coverage and point out the branches nobody exercises. There are also automations that run the suite whenever a file is edited, and connectors that open a real browser to validate complete user flows.
Start with the problem you have today. If the project already has tests and you want more coverage, a generation command and a coverage report are enough for the first few weeks. If you are starting a new feature, it is better to adopt the test-first cycle. If what breaks are interface flows, jump to the end-to-end group. Install a few components at a time and keep only the ones you actually use.
21 hand-picked components, from 4 different angles.
The most common case: there is code in production and little or no coverage. These components read what exists and produce unit and integration tests that follow the project's conventions.
Point it at a file or a component name and get the complete test file, already aligned with the framework detected in the project (Jest, Vitest, Mocha or Jasmine).
Generate a complete test file for a specified source file or component. Use when the user explicitly asks to write, create, or generate tests for a sp
Useful when you want to decide the type of test up front: it takes unit, integration, end-to-end or component as an argument, and handles mocking and coverage configuration.
Write comprehensive unit and integration tests with proper mocking and coverage
For anyone who writes in Jest and wants stable conventions: factory functions for fake data, mocking strategies and the discipline of testing behavior instead of implementation.
Jest testing patterns, factory functions, mocking strategies, and TDD workflow. Use when writing unit tests, creating test factories, or following TDD
The Python-side equivalent, with pytest, fixtures, parametrization and mocking of external dependencies, including async code. Choose it if your suite lives in pytest.
Implement comprehensive testing strategies with pytest, fixtures, mocking, and test-driven development. Use when writing Python tests, setting up test
A good fit when there is no suite at all and you need to set up all three layers at once, including test data, factories and the CI pipeline configuration.
Create comprehensive test suites with unit, integration, and e2e tests. Sets up CI pipelines, mocking strategies, and test data. Use PROACTIVELY for t
Works one level above the file: it defines the strategy, spreads the effort across the testing pyramid and sets quality thresholds before anyone writes the first assertion.
Test automation and quality assurance specialist. Use PROACTIVELY for test strategy, test automation, coverage analysis, CI/CD testing, and quality en
When the feature does not exist yet, writing the test before the code changes the design of the result. These components enforce the red, green, refactor cycle instead of letting the model jump straight to the implementation.
The short reference for the cycle, with the three laws of TDD and the rules for each phase. Useful for keeping the assistant disciplined during long sessions.
Test-Driven Development workflow principles. RED-GREEN-REFACTOR cycle.
Writes the failing tests from the context of a GitHub issue, extracting requirements, acceptance criteria and edge cases before any implementation exists.
Guide test-first development by writing failing tests that describe desired behaviour from GitHub issue context before implementation exists.
The next phase: it implements only the minimum needed for the tests to pass and explicitly resists widening the scope beyond what the issue asks for.
Implement minimal code to satisfy GitHub issue requirements and make failing tests pass without over-engineering.
Closes the cycle with duplication removal, design improvements and security best practices, always on the condition that every test stays green.
Improve code quality, apply security best practices, and enhance design whilst maintaining green tests and GitHub issue compliance.
Unit tests do not catch a button that stopped submitting the form. This group covers real user flows in a browser and the visual differences between versions.
For anyone who has not yet chosen between Cypress, Playwright, WebDriver or Puppeteer: it analyzes the project, picks the framework and connects the suite to the CI system you already have.
Configure comprehensive end-to-end testing suite with framework selection and CI integration
Goes deeper into Playwright, with the Page Object Model, persisted authentication state, custom fixtures and parallelization, starting with an interview about the critical flows.
Plan and build comprehensive Playwright E2E test suites with Page Object Model, authentication state persistence, custom fixtures, visual regression,
Gives Claude Code a real browser to navigate, take screenshots and run JavaScript on the page, useful for reproducing a bug before turning it into a test.
A Model Context Protocol server that provides browser automation capabilities using Playwright. This server enables LLMs to interact with web pages, t
When the regression is visual rather than functional: it sets up image comparison across browsers, at several screen sizes, at the component or full-page level.
Setup comprehensive visual regression testing with cross-browser and responsive testing
Having tests is not enough, you need to know whether they are worth anything and make sure they run. Here you will find coverage analysis, the techniques that test the tests themselves and the routine for running them.
Separates line, branch, function and statement coverage, and shows where the gaps are, instead of a single percentage that hides what is missing.
Analyze and improve test coverage with comprehensive reporting and gap identification
A large suite can also be a bad one. It evaluates the effectiveness, maintainability and run time of the existing tests and suggests what to cut or rewrite.
Analyze test suite quality with comprehensive metrics and improvement recommendations
Introduces mutations into the code to see whether any test catches them, with Stryker, PIT, mutmut or cargo-mutants. It is the most honest way to find out whether coverage means anything.
Setup comprehensive mutation testing with framework selection and CI integration
Instead of hand-picked examples, it identifies invariants and generates inputs with fast-check, Hypothesis, QuickCheck or proptest. It pays off in domain logic full of edge cases.
Implement property-based testing with framework selection and invariant identification
A PostToolUse automation that runs the relevant tests as soon as a file is edited, recognizing JavaScript, Python and Ruby projects without extra configuration.
Automatically run relevant tests after code changes. Detects test files and runs appropriate test commands based on file extensions and project struct
Comes with its own scripts to generate suites, analyze coverage and scaffold end-to-end tests, aimed at React, Next.js and Node.js applications.
Comprehensive QA and testing skill for quality assurance, test automation, and testing strategies for ReactJS, NextJS, NodeJS applications. Includes t
Covers the manual side of QA: test plans, written test cases, regression suites and bug reports, with screen validation against Figma files.
Generate comprehensive test plans, manual test cases, regression test suites, and bug reports for QA engineers. Includes Figma MCP integration for des
Each category has its own place. Agents are markdown files in .claude/agents/ inside the project, or in ~/.claude/agents/ if you want them in every project. Skills go in .claude/skills/<name>/SKILL.md and are loaded when the request matches their description. Commands go in .claude/commands/<name>.md and are invoked with a slash, for example /generate-tests src/auth.ts. Automations (hooks) are configuration blocks in settings.json, with the event and the shell command to run. MCP connectors are registered in the MCP server configuration and start through npx when the session begins. Install at project level whenever the configuration depends on the test framework used in that repository.
A chain that works on existing code: first run the coverage command to find out which files are uncovered, then generate tests file by file for the most critical modules, and only at the end turn on the automation that runs the suite on every edit. That way you avoid having an automation fail on every save while the suite is still incomplete. For the modules where a bug costs money or data, add mutation testing: if the mutations survive, the tests exist but verify nothing. For new features the chain is different: the TDD skill, the red-phase agent, the green-phase agent, the refactoring agent.
Tests generated from existing code describe the current behavior, bugs included. If the goal is to validate requirements, someone has to review each assertion and confirm it describes what should happen, not what happens. The coverage percentage is not quality either: you can reach high numbers without a single useful assertion, which is why mutation analysis exists. With end-to-end tests, expect slowness and intermittent failures, especially on screens with animations or changing data. And none of these components decides what is critical in your product; that part is still yours.
No, and it is not advisable. Every skill and every agent takes up context and they compete with each other when they do similar things. Choose one component per real need: one to generate tests, one to measure coverage, and add the end-to-end ones only when you have interface flows worth covering.
Prompts and resources curated from international sources, normalized and categorized: over 11 thousand. A Doutor AI bot checks the sources every day and brings in what is new.
Need a tailor-made solution?
Not sure where to start with AI in your business? Get a free assessment and a tailored plan - no commitment.
Doutor AI gives you 1,859 ready-to-copy AI prompts, by industry and in plain English - plus a complete technical library for those who want to go further.
