# Agents, skills and commands for automated testing

> Components to write, run and evaluate tests with Claude Code.

- Source: https://doutorai.pt/en/for/automated-testing
- Site: Doutor AI (https://doutorai.pt/en) - AI tools for small businesses

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.

## Write tests for code that already exists

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.

- **generate-tests** (Commands): 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). [page](https://doutorai.pt/en/components/commands__generate-tests)
- **write-tests** (Commands): 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. [page](https://doutorai.pt/en/components/commands__write-tests)
- **testing-patterns** (Skills): 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. [page](https://doutorai.pt/en/components/skills__testing-patterns)
- **python-testing-patterns** (Skills): The Python-side equivalent, with pytest, fixtures, parametrization and mocking of external dependencies, including async code. Choose it if your suite lives in pytest. [page](https://doutorai.pt/en/components/skills__python-testing-patterns)
- **test-automator** (Agents): 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. [page](https://doutorai.pt/en/components/agents__test-automator)
- **test-engineer** (Agents): 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. [page](https://doutorai.pt/en/components/agents__test-engineer)

## Work in TDD, test first

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.

- **tdd-workflow** (Skills): 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. [page](https://doutorai.pt/en/components/skills__tdd-workflow)
- **tdd-red** (Agents): Writes the failing tests from the context of a GitHub issue, extracting requirements, acceptance criteria and edge cases before any implementation exists. [page](https://doutorai.pt/en/components/agents__tdd-red)
- **tdd-green** (Agents): 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. [page](https://doutorai.pt/en/components/agents__tdd-green)
- **tdd-refactor** (Agents): Closes the cycle with duplication removal, design improvements and security best practices, always on the condition that every test stays green. [page](https://doutorai.pt/en/components/agents__tdd-refactor)

## End-to-end, browser and visual regression

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.

- **e2e-setup** (Commands): 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. [page](https://doutorai.pt/en/components/commands__e2e-setup)
- **playwright-e2e-builder** (Skills): Goes deeper into Playwright, with the Page Object Model, persisted authentication state, custom fixtures and parallelization, starting with an interview about the critical flows. [page](https://doutorai.pt/en/components/skills__playwright-e2e-builder)
- **playwright-mcp-server** (Connectors): 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. [page](https://doutorai.pt/en/components/mcps__playwright-mcp-server)
- **setup-visual-testing** (Commands): 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. [page](https://doutorai.pt/en/components/commands__setup-visual-testing)

## Coverage, suite quality and automatic runs

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.

- **test-coverage** (Commands): Separates line, branch, function and statement coverage, and shows where the gaps are, instead of a single percentage that hides what is missing. [page](https://doutorai.pt/en/components/commands__test-coverage)
- **test-quality-analyzer** (Commands): 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. [page](https://doutorai.pt/en/components/commands__test-quality-analyzer)
- **add-mutation-testing** (Commands): 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. [page](https://doutorai.pt/en/components/commands__add-mutation-testing)
- **add-property-based-testing** (Commands): 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. [page](https://doutorai.pt/en/components/commands__add-property-based-testing)
- **test-runner** (Automations): A PostToolUse automation that runs the relevant tests as soon as a file is edited, recognizing JavaScript, Python and Ruby projects without extra configuration. [page](https://doutorai.pt/en/components/hooks__test-runner)
- **senior-qa** (Skills): 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. [page](https://doutorai.pt/en/components/skills__senior-qa)
- **qa-test-planner** (Skills): Covers the manual side of QA: test plans, written test cases, regression suites and bug reports, with screen validation against Figma files. [page](https://doutorai.pt/en/components/skills__qa-test-planner)

## Where each type of component is installed

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.

## How to chain generation, coverage and runs

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.

## What these components do not solve

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.

## Keep reading

- [Test Engineer Agent](https://doutorai.pt/en/how-to/subagents--test-engineer)
- [Expand Unit Tests](https://doutorai.pt/en/how-to/slash-commands--unit-test-expand)

## Frequently asked questions

### Do I need to install all these components?

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.

### Can I trust automatically generated tests?

They are a starting point, not a final result. The model writes the assertions from the code it reads, so wrong behavior tends to get recorded as if it were correct. Always review the edge cases and delete the tests that just repeat the implementation line by line, because those break with every refactoring.

### What is the difference between an agent, a skill and a command in this context?

A command is an action you trigger yourself with a slash, useful for one-off tasks such as generating a test file. A skill is knowledge that Claude Code loads when the request fits its description, for example pytest conventions. An agent runs in a separate context and suits long work, such as building an entire suite.

### Does this work with the language I use in my project?

It depends on the component. Several detect the framework from the configuration files and cover JavaScript, TypeScript and Python. The mutation and property-based testing commands also support Java, Rust, Go, C# and others. For pytest and for Jest there are dedicated skills on this page, with patterns specific to each one.

### Is it worth adopting TDD on a project that is already underway?

It is, if you apply it only to new code. Rewriting the history in TDD rarely pays off. The practical approach is to use the red, green and refactor phase agents for each new feature or bug fix, and to handle the old code with test generation and coverage analysis, which is faster.

---
Content by Doutor AI (https://doutorai.pt/en). When quoting, please cite the source: https://doutorai.pt/en/for/automated-testing