Agent Functional Testing: Test Cases, Coverage, and Limits

A support agent goes into a demo and handles nine questions perfectly. It ships. In week one it issues a refund above the approval limit, tells a customer their order shipped when it did not, and answers a question about a product line it was never given. Nobody can say which test would have caught any of it, because there were no tests, only a demo that went well.

That gap is what functional testing has always filled. The discipline transfers to agents. The artifacts do not, and that is where most teams stall.

The phrase is used for two opposite activities, and conflating them wastes a lot of planning time.

• The agent as the tool - an AI agent reads your tickets and designs, then generates and runs functional tests against your application. The system under test is still the app, and everything you already know about functional testing still applies.
• The agent as the system under test - the agent itself is the thing being checked, and the question is whether it does what it was built to do. This has no settled test-case practice behind it, which is why it is the subject of this article.

Agent functional testing, in the second sense, is requirements-based verification of an AI agent: you state what the agent must do, derive test cases from those statements, and check each one against a stated expectation. The definition is deliberately ordinary. What changes is that the input is natural language, the output is an action plus a reply, and no two runs are guaranteed to take the same route.

If the general practice is unfamiliar, the functional testing guide covers the fundamentals this article assumes.

Most teams building agents reach for evals first, then wonder why a rising score does not stop incidents. The two instruments answer different questions.

Getting the grader itself wrong is a live risk, not a theoretical one. In a study of agentic benchmark design, researchers found that flawed task setup or reward design can under- or overestimate an agent's performance by up to 100% in relative terms, citing among other examples a widely used benchmark that counted empty responses as successful, per Establishing Best Practices for Building Rigorous Agentic Benchmarks on arXiv.

A functional test is easier to keep honest because its expectation is written by hand and points at one thing. That is the argument for having both, and for writing the functional layer first. For the scoring side in depth, see the guide to AI agent evaluation.

You cannot derive test cases from "it is a customer service agent". The spec is the contract the tests are written against, and it needs three kinds of statement.

• Must do - the capabilities, each phrased as a complete action with its object. "Issue a refund for a delivered order" is testable; "handle refunds" is not.
• Must never do - the hard constraints, including the limits with numbers in them. "Never refund above 200 units of currency without approval" gives you a boundary to test on both sides.
• Must escalate - the handoff conditions, stated as triggers rather than as judgement. "After three failed resolution attempts, or when the customer asks for a human" is a trigger you can drive.

Write these before the tests and keep them next to the tests. When the agent's role changes, the spec changes first, because a test suite measured against a stale spec produces false failures on new correct behaviour and quietly misses real regressions.

Note: An agent that acts on real systems has to be checked against those systems rather than against its own account of what it did. TestMu AI covers that layer. Try it free.

Each line of the spec becomes one or more test conditions, and each condition becomes a case. The mechanical part is familiar; two things about it are specific to agents.

Every case carries two expectations, not one. An agent produces an effect on a system and a reply describing that effect, and the two can disagree. A case that only checks the effect passes an agent that lies about it; a case that only reads the reply passes an agent that did nothing.

Expectations are conditions, not sequences. The same request can legitimately route through different tools on different runs, so pinning an exact tool order produces a test that fails on correct behaviour. State what must be true when the run finishes and stay silent about how the agent got there, which is the same principle behind end to end agent testing.

Natural language looks like an infinite input domain, which is why teams stop at a handful of happy-path prompts. It partitions like any other domain once you decide what the classes are.

The last row is the one teams add last and should add first. An agent reads content it did not author, and text inside that content can carry instructions, so treating it as an input class rather than a security afterthought is what gets it tested at all.

A written format keeps cases comparable and makes gaps visible. This one has held up across the agent suites worth copying.

id: REF-004
capability: Issue a refund for a delivered order
input_class: past the boundary
precondition:
  order: A-1183 exists, status delivered, value 240
  approval_limit: 200
input: "Refund order A-1183 in full, the item arrived damaged."

expected_effect:
  - no refund record created for A-1183
  - an approval request exists, assigned to a human
  - no notification sent to the customer

expected_response:
  - states the request needs approval
  - does not claim the refund was issued
  - gives the customer a next step

pass_criteria: every line of expected_effect and expected_response holds

Three details do the work here. The precondition is stated as data you can create, so the case is repeatable. The effect is written as things you read back from the system, not as things the agent says. The response expectation includes a negative clause, because "does not claim the refund was issued" is the assertion that catches a confidently wrong agent.

Code coverage does not transfer. The behaviour under test lives in a model and a prompt rather than in branches you can instrument, so counting executed lines tells you nothing about whether a rule was exercised.

The workable substitute is a grid: capabilities down one axis, input classes across the other, and a cell marked when at least one case exercises that pairing and asserts an outcome. Six capabilities against six input classes gives thirty-six cells, and a suite of twelve cases will show you exactly which twenty-four you have never tried.

Two rules keep the grid honest. Count a cell only when the case asserts something, since a run that completes without an assertion is a demo. And report the empty cells alongside the pass rate, because a suite covering only the clear in-scope column will show a perfect pass rate while testing the one thing that was never in doubt. Where several agents hand work to each other, the same grid extends across the handoffs, which the guide to multi agent testing covers in detail.

A pass on every requirement can still ship an agent people dislike. Four qualities sit entirely outside the functional layer.

• Tone - the agent is technically correct and sounds cold or dismissive, which never fails a functional check and shows up immediately in satisfaction scores.
• Latency - a correct answer after a long silence is a different product from a correct answer in two seconds, and neither fails the case.
• Cost - an agent that reaches the right outcome after twenty tool calls passes every assertion and quietly triples the bill.
• Consistency - the same case can pass on one run and fail on the next, which a single pass records as green.

Consistency is the one that changes how you run the suite: repeat the critical cases and treat an intermittent pass as a failure rather than as noise. The split between the two categories is the same one covered in functional and non-functional testing, and it applies to agents with the weighting shifted toward the non-functional side.

The AI agent testing platform from TestMu AI automates the parts of the process above that are tedious by hand.

• Scenarios from your spec - you upload the document that describes the agent, and the platform generates 60 to 100 or more scenarios per workflow, distributed across edge cases, personas, adversarial inputs, and compliance situations rather than sampled at random.
• Parallel execution - specialised testing agents run the scenarios concurrently, each one probing a specific failure mode and interacting with the endpoint the way a real user would.
• Per-scenario verdicts - results come back as pass or fail per scenario with per-metric scores aggregated across the run, plus annotated transcripts for every failure showing which turn caused it and what the expected behaviour was.
• Confidence alongside the score - each metric carries a confidence level driven by scenario volume, so a green verdict at low confidence reads as insufficient evidence rather than as a clearance.

Two honest limits are worth stating. A green verdict covers the scenarios that were run with the personas configured, so a narrow configuration produces a narrow verdict. And the single biggest driver of result quality is the agent description you upload, which is the same capability spec this article started with, so the platform does not remove that work from you.

For the wider picture of where this sits, the AI agent testing hub covers the surrounding practice.

Write the capability spec first. Even a short one, with the must-do lines, the must-never lines with their numbers, and the escalation triggers, gives you something to derive cases from and turns "the demo went well" into a claim you can check.

Then draw the grid, fill in the cells you can, and publish the empty ones next to the pass rate. The empty cells are the finding. Everything after that is repetition: add the boundary and adversarial classes, repeat the critical cases to catch inconsistency, and keep the spec current as the agent changes. For the faster gate that runs ahead of this suite on every prompt edit, see agent smoke testing.

To run this against your own agents, create a free TestMu AI account and start with the getting started documentation.