Unit testing with Claude Code and Codex: build a verifiable team workflow

AI-generated unit tests are useful when the team verifies that they can actually detect a defect. Claude Code and Codex can propose scenarios and assertions, but a passing test may reproduce the same mistake as the implementation. Start from a business rule that is independent of the code.

For a software services team, success means greater confidence in delivery: explicit expected behaviour, relevant boundaries and reproducible execution. The number of generated tests is not a sufficient objective.

Technical guide prepared with AI assistance on 17 September 2026. The example is pedagogical, contains no client data and does not validate an entire application. The cover is an AI-generated conceptual illustration.

Begin with the contract

Write valid inputs, expected outputs and error handling before asking for tests. If a rule is ambiguous, the business owner decides. The agent must not infer desired behaviour solely from the current implementation.

For an order quantity, assume that only integers from 1 to 100 inclusive are valid. Strings, missing values and non-finite numbers must be rejected.

A generated test that accepts the string "2" because the implementation converts it implicitly would be wrong under this contract. It would validate existing behaviour instead of the agreed rule.

Review a case matrix first

Review this matrix before generating assertions. For a real project, add cases reflecting important client rules and historical defects.

The agent may suggest additional scenarios. Assess them rather than accepting every proposal. One rare but critical case can matter more than a hundred equivalent variants that increase maintenance work.

An executable Node.js example

Place this function in a file named quantity.mjs:

export function isValidQuantity(value) {
  return Number.isInteger(value) && value >= 1 && value <= 100;
}

Place the tests in quantity.test.mjs in the same directory:

import test from "node:test";
import assert from "node:assert/strict";
import { isValidQuantity } from "./quantity.mjs";

test("accepts integers at the boundaries and within the domain", () => {
  for (const value of [1, 2, 100]) {
    assert.equal(isValidQuantity(value), true, String(value));
  }
});

test("rejects values outside the contract", () => {
  for (const value of [
    0,
    -1,
    101,
    1.5,
    "2",
    true,
    null,
    undefined,
    NaN,
    Infinity,
  ]) {
    assert.equal(isValidQuantity(value), false, String(value));
  }
});

Run node --test quantity.test.mjs with a Node.js version supporting these modules. The example uses the official Node.js test runner and strict assertions, without an external dependency.

This small case tests neither a web interface nor a database or authorisation boundary. It demonstrates how a rule and its limits become readable assertions.

Ask the agent to work within that contract

A task instruction should state the rule, scope and evidence required. It should not allow the implementation to be changed arbitrarily just to produce green output.

Propose a case matrix from the supplied business rule.
Ask for clarification where a rule is ambiguous.
Write tests using the framework already present in the repository.
Do not change the implementation during this step.
Run targeted tests and report the command and its result.
Identify uncovered scenarios and checks that could not run.

The Claude Code best-practice guidance and Codex AGENTS.md documentation can help structure repository guidance. Actual execution and review remain necessary.

Prove that a broken rule makes the test fail

In an isolated training copy, temporarily replace the inclusive upper boundary with an exclusive one. The case for 100 must fail. If the suite remains green, it may not test that boundary or may not execute the intended code.

Restore the correct function and rerun the suite. This deliberate mutation is a validation exercise, not a change to deliver.

For a larger application, targeted mutations might invert a comparison or remove an error check. Keep the exercise inside an authorised test environment; do not introduce a dangerous defect into shared or production systems.

Common weaknesses in generated tests

A weak assertion. Checking only that a response exists does not verify its content or business meaning.

Mocks that hide the behaviour. Replacing every important dependency with a predetermined response may say little about real integration.

The same algorithm on both sides. Recalculating the expected result with implementation logic can reproduce the same bug. Use independently validated examples.

A test that never runs. A plausible file may be ignored by discovery rules. Check the command, discovered tests and executed count.

Changing expectations to accept a regression. A changed expected result needs a business justification, not merely the desire for green output.

Integrate testing into delivery

The developer prepares cases, the agent proposes tests and the developer runs and reviews them. A reviewer checks their connection to the ticket. Continuous integration repeats the commands in a clean environment.

Pin the versions and dependencies needed for reproducibility. Reduce reliance on time, network and shared mutable data. An intermittent test can make an otherwise useful validation signal unreliable.

Complement unit checks with integration and functional tests according to risk. A green local suite is neither proof of deployment nor confirmation of production behaviour.

Measure value, not volume

Track regressions caught before merge, escaped defects, review effort and test maintenance. Coverage can be informative, but it must be interpreted alongside assertion quality.

The ROI guide includes this work in total delivery cost. For older applications, the legacy maintenance workflow explains how to begin with characterisation tests.

Frequently asked questions

Can an agent write all tests without human involvement?

It can propose many tests, but the team must validate the rules, assertions and scope. A large misdirected suite can be costly while missing important defects.

Does 100% coverage guarantee quality?

No. Executing every line does not establish that assertions check the correct behaviour or that business scenarios are complete.

Can the same agent write implementation and tests?

Yes, but the test contract should remain independent. Predetermined cases and human review reduce the risk of repeating the same error.

Organise a technical workshop

Hunter BI can scope an exercise around an authorised module, an explicit rule and the existing framework. Expected outputs include cases, tests, execution evidence and a review checklist.

Request a unit testing workshop, or explore Claude Code training and OpenAI Codex training.