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	A contract-led test change and an application acceptance check
How do I test a change while working in Cursor?	Testing with Cursor	A diff-based coverage matrix and reviewed tests
How do I use Codex to add regression coverage?	Testing with Codex	A bounded repository task with command and result evidence
Can I use Copilot, Gemini CLI, or Windsurf?	Other coding agents	Client-specific MCP configuration and a shared verification workflow
How do I test a function?	Unit testing	Boundary, invalid-input, and regression assertions
How do I test components working together?	Integration testing	A test across a real boundary with isolated data
How do I test a business requirement?	Functional testing	A decision table tied to observable outcomes
How do I test a complete user journey?	End-to-end testing	An application workflow with state verification and cleanup
How do I write reliable Playwright tests with an agent?	Playwright testing	A runnable browser fixture and a path to application tests
Should I use Playwright, Cypress, Selenium, or my unit runner?	Framework selection	A choice based on the testing boundary and existing stack
Can I own and run the generated code elsewhere?	Export and portability	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	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	Requirement-derived assertions with a runnable permission fixture and defect checks
How do I test login, logout, and session revocation?	Authentication and session testing	Browser state, server identity, and denial of a previously valid session
How do I migrate Cypress tests to Playwright?	Cypress-to-Playwright migration	Request observation, persisted state, and equivalent business assertions
How do I generate and review API tests from OpenAPI?	OpenAPI contract testing	Response schema, business values, authorization, and execution evidence
How do I find and fix flaky tests in CI?	Flaky-test diagnosis	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, 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. For changes spanning CI, releases, and review, use the agentic PR evidence checklist.

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 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, 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. 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 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.