> For the complete documentation index, see [llms.txt](https://learning.contextqa.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learning.contextqa.com/testing-with-ai-coding-agents/ai-agent-testing.md).

# Testing with AI Coding Agents

Write and verify unit, integration, functional, and end-to-end tests with AI coding agents, then connect ContextQA MCP for application testing and evidence.

## Quick answer

Use an AI coding agent to read requirements, propose test cases, write tests in your existing framework, and run them against a controlled fixture. Review the assertions and verify that a known defect makes the tests fail. Connect ContextQA through MCP when you want the agent to create and execute managed application tests and retrieve their results. Keep repository test results, ContextQA execution evidence, and exported code as separate, traceable artifacts.

## Choose your starting point

You do not need to change frameworks or buy a testing platform to follow the generic workflows in this collection. Start with your current repository and one behavior that matters. Each guide then explains the additional ContextQA workflow and what you must verify before relying on it.

| Your question                                                  | Start here                                                                         | What you will produce                                                |
| -------------------------------------------------------------- | ---------------------------------------------------------------------------------- | -------------------------------------------------------------------- |
| How do I write tests from the terminal with Claude Code?       | [Testing with Claude Code](/testing-with-ai-coding-agents/claude-code-testing.md)  | A contract-led test change and an application acceptance check       |
| How do I test a change while working in Cursor?                | [Testing with Cursor](/testing-with-ai-coding-agents/cursor-testing.md)            | A diff-based coverage matrix and reviewed tests                      |
| How do I use Codex to add regression coverage?                 | [Testing with Codex](/testing-with-ai-coding-agents/codex-testing.md)              | A bounded repository task with command and result evidence           |
| Can I use Copilot, Gemini CLI, or Windsurf?                    | [Other coding agents](/testing-with-ai-coding-agents/other-coding-agents.md)       | Client-specific MCP configuration and a shared verification workflow |
| How do I test a function?                                      | [Unit testing](/testing-with-ai-coding-agents/unit-testing.md)                     | Boundary, invalid-input, and regression assertions                   |
| How do I test components working together?                     | [Integration testing](/testing-with-ai-coding-agents/integration-testing.md)       | A test across a real boundary with isolated data                     |
| How do I test a business requirement?                          | [Functional testing](/testing-with-ai-coding-agents/functional-testing.md)         | A decision table tied to observable outcomes                         |
| How do I test a complete user journey?                         | [End-to-end testing](/testing-with-ai-coding-agents/end-to-end-testing.md)         | An application workflow with state verification and cleanup          |
| How do I write reliable Playwright tests with an agent?        | [Playwright testing](/testing-with-ai-coding-agents/playwright-testing.md)         | A runnable browser fixture and a path to application tests           |
| Should I use Playwright, Cypress, Selenium, or my unit runner? | [Framework selection](/testing-with-ai-coding-agents/framework-selection.md)       | A choice based on the testing boundary and existing stack            |
| Can I own and run the generated code elsewhere?                | [Export and portability](/testing-with-ai-coding-agents/export-and-portability.md) | A reviewed export and a standalone acceptance record                 |

## Solve a specific testing problem

| Your question                                            | Guide                                                                                                     | What you will verify                                                                |
| -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| Do I need Playwright MCP, CLI, or Test Agents?           | [Choose the right Playwright workflow](/testing-with-ai-coding-agents/playwright-mcp-cli-test-agents.md)  | Browser exploration, repeatable tests, and managed execution have different outputs |
| How do I know tests for AI-generated code catch defects? | [Test AI-generated code](/testing-with-ai-coding-agents/testing-ai-generated-code.md)                     | Requirement-derived assertions with a runnable permission fixture and defect checks |
| How do I test login, logout, and session revocation?     | [Authentication and session testing](/testing-with-ai-coding-agents/playwright-authentication-testing.md) | Browser state, server identity, and denial of a previously valid session            |
| How do I migrate Cypress tests to Playwright?            | [Cypress-to-Playwright migration](/testing-with-ai-coding-agents/cypress-to-playwright.md)                | Request observation, persisted state, and equivalent business assertions            |
| How do I generate and review API tests from OpenAPI?     | [OpenAPI contract testing](/testing-with-ai-coding-agents/openapi-contract-testing.md)                    | Response schema, business values, authorization, and execution evidence             |
| How do I find and fix flaky tests in CI?                 | [Flaky-test diagnosis](/reporting/flaky-test-detection.md)                                                | A reproducible failure, a targeted repair, and preserved first-attempt evidence     |

## What kind of test should the agent create?

Testing levels describe the boundary exercised. Functional testing describes the purpose of a check, so a functional test can also be a unit, integration, or end-to-end test.

| Level or purpose | Good first question                                                  | Typical execution environment                       | What it does not prove alone                         |
| ---------------- | -------------------------------------------------------------------- | --------------------------------------------------- | ---------------------------------------------------- |
| Unit             | Does this shipping-fee function handle the threshold correctly?      | Your repository's test runner                       | That checkout calls the function or saves the result |
| Integration      | Does this HTTP handler validate input and return the service result? | A local or isolated service fixture                 | That every production dependency behaves identically |
| Functional       | Can a viewer read a report but not export it?                        | The narrowest layer that can verify the requirement | That a hidden button enforces server authorization   |
| End-to-end       | Can a user create a record, reload, and retrieve the saved value?    | An actual application and its required services     | Every possible role, browser, or backend failure     |

Prefer the smallest test that can detect the specific defect. Add a higher-level test when the risk lies in wiring, authentication, persistence, or a user journey crossing multiple components. Repeating every input combination through a browser usually adds runtime and maintenance without adding a different assertion.

## Before you ask an agent to write tests

Gather these inputs in the repository or task context:

1. **Expected behavior:** acceptance criteria, including one denied or invalid case. Requirements decide the expected result; the current implementation can be wrong.
2. **Existing conventions:** package scripts, test runner, fixture patterns, naming, and repository instructions. Ask the agent to inspect these before proposing dependencies.
3. **Test environment:** an approved local or staging target, its build identifier, and a way to reset disposable data.
4. **Execution access:** distinguish commands the agent can run locally from actions available to an authenticated remote MCP server.
5. **Completion criteria:** the exact checks, artifacts, and unresolved limitations a reviewer needs.

Avoid using customer records to make a tutorial realistic. A dedicated test user and synthetic records make both cleanup and failure investigation easier. Provide credentials through the environment's approved mechanism, not a copied secret in a prompt or committed fixture.

## A reusable generic workflow

### 1. Inspect the change before generating code

Ask the agent to identify the touched behavior, existing coverage, and relevant commands. Run the current targeted tests first. Save a failing baseline separately so an existing failure is not attributed to the new change.

```
Read the repository instructions, test scripts, and changed files.
Do not edit yet. Identify the behavior this change could break.
Propose a small test matrix: requirement, layer, fixture, action,
expected result, and the defect each assertion would catch.
Separate existing failures from gaps in coverage.
```

### 2. Review the assertions before the implementation

Approve a concrete expectation such as “a viewer receives a denied response and no export is created.” “The page loaded” is insufficient if the requirement concerns permissions. Check that expected values come from the requirement rather than from calling the same production function under test.

### 3. Implement a small, reviewable test change

Keep the existing framework unless a missing capability justifies a change. Use stable labels or test identifiers for UI interactions, isolated fixtures for state, and explicit outcomes. Ask the agent to explain any new dependency or application code change separately from test creation.

### 4. Run the tests and prove they can fail

Preserve the first attempt and exact command. In a disposable fixture or temporary branch, introduce the specific defect the assertion is meant to catch. Confirm failure, restore the correct behavior, and confirm success. Never introduce a defect into a shared staging or production deployment just to validate a tutorial.

A rerun that passes after a timeout does not erase the original failure. Record flaky behavior, skipped tests, and retries so the reviewer can distinguish a deterministic result from an unstable signal.

### 5. Hand off evidence with the change

Use a short record like this:

```
Requirement and risk:
Application commit/build:
Test files and framework:
Fixture, role, and environment:
Exact commands and first-attempt exit codes:
Assertions checked:
Known-defect check and restoration result:
Artifacts or execution links:
Skipped checks, retries, and unresolved limitations:
Data cleanup result:
```

This record works for code review, a QA handoff, or a pilot evaluation. It does not need a new platform to be useful.

## Add ContextQA through MCP

MCP gives a compatible coding agent access to ContextQA tools after authentication. It does not give a hosted server automatic access to your laptop, replace your local test runner, or turn test generation into a passed execution.

1. Follow [MCP installation and authentication](/mcp-server/installation-and-setup.md), or the configuration in your client guide above.
2. Discover the tools and schemas available to your account. Use a read-only listing to confirm the intended workspace and access.
3. Search for an existing case before creating another. Provide one approved application workflow, its starting state, test role, and explicit business assertions.
4. Review the generated case and verification steps. Some generation tools also run tests; inspect the tool's side effects before calling it.
5. Execute the reviewed case in the approved environment. Save the test-case, execution, and result identifiers returned by the tools.
6. Retrieve the final result and step evidence. A job marked complete is not necessarily a passed test; missing evidence should remain visible in the report.

Use this prompt after setup:

```
Inspect the available ContextQA tools and their input schemas.
Confirm the workspace with a read-only call, then look for an existing
case matching the acceptance criteria below. Propose the smallest
application test and list the expected assertions before creating it.
Use only the approved staging URL and synthetic data I provide.
Keep my local unit-test results separate from ContextQA results.
After an approved run, return the final verdict, identifiers, step
results, available evidence links, and anything not verified.
```

For the full walkthrough, use [create and run your first MCP test](/mcp-server/first-test-tutorial.md). For changes spanning CI, releases, and review, use the [agentic PR evidence checklist](/evaluation-and-governance/agentic-pr-evidence-checklist.md).

## Keep framework ownership and export explicit

You can retain repository-native unit and integration tests while using ContextQA for selected application workflows. There is no requirement to migrate everything at once.

When evaluating exported Playwright code, inspect the returned file manifest, credentials, fixtures, assertions, and manual checkpoints before running it. A successful export is an artifact-generation result; a clean standalone run with a seeded-defect check establishes something stronger. The [export and portability guide](/testing-with-ai-coding-agents/export-and-portability.md) explains this acceptance process and the current limitations around AI steps.

## Frequently asked questions

### Can a coding agent write all of our tests?

It can help create and maintain many kinds of tests, but someone still needs to define the expected behavior, review the assertions, and decide what evidence is sufficient. Start with one risky change and measure useful defect detection and review effort before expanding.

### Does ContextQA MCP run Jest, Vitest, pytest, or JUnit inside my repository?

Do not assume that. Run repository tests through the coding agent's authorized local tools or CI. Use ContextQA's discovered tools for the supported application-testing workflow. A repository parser or migration feature is not proof that the original runner and assertions execute unchanged.

### Should I create both a local browser test and a ContextQA case?

Only when the second representation serves a clear purpose, such as a portability evaluation or managed regression workflow. Record which version is authoritative and how changes are reviewed; exports are snapshots, not automatic two-way synchronization.

### Will these guides guarantee search or AI-answer visibility?

No. They provide direct answers, distinct tasks, worked examples, and connected references so readers can evaluate and apply the guidance. Search indexing and AI citations require separate observation; neither follows automatically from publishing more pages.

## Try one representative workflow

[Connect your coding agent to ContextQA MCP](/mcp-server/installation-and-setup.md), then choose one happy path and one denied or invalid case from these guides.

If you need help evaluating authentication, evidence, CI ownership, or export boundaries, [book a testing workflow demo](https://contextqa.com/book-a-demo/?utm_source=learning.contextqa.com\&utm_medium=referral\&utm_campaign=docs_demand_gen\&utm_content=ai_agent_testing_hub). Bring an acceptance criterion and an approved test environment so the discussion can focus on your actual decision.

## Sources and maintenance

Client-specific setup and framework references are cited in the corresponding guides. The [ContextQA MCP documentation](https://mcp.contextqa.com/docs) describes the hosted connection; the authenticated tool manifest is the authority for the tools available to your workspace. Reviewed September 25, 2026. Recheck commands, schemas, and export behavior when upgrading a client or server.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://learning.contextqa.com/testing-with-ai-coding-agents/ai-agent-testing.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.