Summary: At VAON, code written with Claude Code reaches the pull request together with its unit and end-to-end tests. Done criteria from the plan become test cases. Engineers read AI-written tests with four questions: does it test the business rule or the implementation, can it ever fail, does a mock hide real behavior, which failure cases are missing.
Contents
- Why do tests ship in the same pull request as AI-written code?
- How do done criteria from the plan become test cases?
- What do engineers ask when reading AI-written tests?
- What evidence does a pull request with tests leave you?
- What can AI-written tests not replace?
- FAQ
1. Why do tests ship in the same pull request as AI-written code?
Tests ship in the same pull request because a reviewer needs the code and the proof together. If tests come later, the code is merged with nothing proven. At VAON the main branch is protected: no review, no merge.
AI writes tests quickly, so "tests later" has no excuse left. The real question is whether they check the right thing. A green suite says little if it is not tied to requirements.
Tests in the pull request are steps 6 and 7 of VAON's Claude Code development workflow. It is the standard VAON applies to most projects, not yet all.
2. How do done criteria from the plan become test cases?
Every done criterion in the implementation plan becomes at least one test case. Engineers list the test cases from the criteria before reading the code. The criteria were made testable when the team validated the implementation plan.
An illustration, not from any client project:
| Done criterion (illustration) | Unit test | End-to-end test |
|---|---|---|
| Orders at or above the approval limit go to "awaiting manager approval" | Status function with orders below, exactly at and above the limit | Staff create a large order; the manager sees it in the approval queue |
| Staff cannot see orders from another branch | Every query filters by branch | Log in as branch A staff, open a branch B order URL directly, get refused |
| Clicking Save twice does not create two orders | Resending the same request ID writes once | Click Save twice quickly; the list shows one order |
Unit tests check rules inside single functions and run fast, so they suit edge cases like "exactly at the limit". End-to-end tests run the whole flow as a user would. They are slower and flakier, so VAON keeps them for main flows and permissions.
Anthropic's guide to working with tests in Claude Code advises being specific about the behavior to verify. Done criteria supply exactly that.
3. What do engineers ask when reading AI-written tests?
VAON engineers read AI-written tests with four questions, because AI tends to test the code it just wrote, not the requirement.
| Warning sign | What it looks like | Engineer's question |
|---|---|---|
| Tests the implementation, not the rule | Expected value computed with the same formula as the code; counting calls to internal functions | Did the expected number come from the spec or from the code? |
| Can never fail | No assertion, an assertion of the obvious, errors caught and ignored | If I break the code on purpose, does it turn red? |
| Mock hides real behavior | Mock returns what the test expects, or replaces the part under test | Is the mocked part the very thing we need to prove? |
| Missing failure cases | Only the happy path; no empty, duplicate or unauthorized input | What does the spec say happens on failure, and which test checks it? |
The first sign is the hardest to spot. A test using the code's own formula stays green even when the formula is wrong, so engineers write expected values by hand, from the spec.
When a test goes red, an engineer who has read the spec decides whether the code or the test is wrong. AI does not edit the test until it passes. How to break code on purpose to probe a test is covered in our AI-generated code review process.
4. What evidence does a pull request with tests leave you?
A pull request with tests leaves evidence you can check later: which criterion is covered by which test, which command ran, and what it returned. The description maps criteria to tests and names any criterion without a test, with the reason.
Claude Code's best practices recommend asking Claude for evidence: the command it ran and its output. The docs note that "all tests pass" on its own tells you very little.
VAON engineers use Claude Code and GitHub Copilot every day. AI writes tests and re-reads code, and people check before release. Every pull request on every project also passes automated gates: secret scanning, dependency scanning and static analysis. Every project keeps review and test records that clients can see. "Who checks the code the AI writes?" was one of the three questions clients asked VAON most in 2026. Tests inside the pull request, with the approver's name attached, are part of the answer.
5. What can AI-written tests not replace?
AI-written tests only check what the spec says, so some things they cannot replace:
- Your acceptance testing. Whatever the spec missed, the tests miss too. You still test against a user-focused checklist.
- Unwritten business rules. AI cannot test a rule it does not know.
- Reviewer judgment. High coverage can still be made of tests that never fail. VAON does not promise a general coverage figure.
Two more limits. Flaky end-to-end tests get ignored, so keep them few and stable. Without permission to put code into AI tools, engineers write tests themselves, which is slower. The QA team's side of this is in our four-step AI verification loop for QA.
6. FAQ
What test coverage percentage is enough? VAON does not promise a general coverage figure. Coverage shows which lines ran during testing, not whether the tests check the right rule. A better question: does every done criterion in the plan have a matching test, and if one does not, why not?
I don't code. How can I check the tests? You do not need to read test code. Look at the pull request description: which criterion is checked by which test, and the result of the latest run. Pick a rule that matters to you, such as who may approve an order, and ask the team which test checks it.
If AI writes both the code and the tests, isn't it grading its own work? That risk exists, and VAON handles it in three places. Test cases come from the plan's done criteria, not from the code. Engineers write expected values from the spec. Then another engineer reviews the pull request before the team lead approves the merge, and the main branch accepts no unreviewed code.
If there are end-to-end tests, do we still need acceptance testing? Yes. End-to-end tests follow scenarios the development team wrote from the spec. Acceptance testing is when you, the real users, check the system the way your work actually runs. At VAON you test against a user-focused checklist, with a screenshot of the result for each item.
Does writing tests with the code make the project more expensive? AI speeds up writing repetitive tests, so that part costs less. Reading and fixing tests still takes engineers, and VAON does not cut that work. That is why VAON does not promise a general cost reduction. Quotes are based on the scope in the locked spec, and tests are part of that scope.
One thing you can do today: open a recent pull request on your project. Pick one done criterion from the spec and ask your team, "Which test checks this, and would it turn red if the code were wrong?"
To see how this would work on your project, book a free 60-minute consultation. VAON's CEO joins, no documents needed, no commitment.
