Testing Strategy by Maturity Stage: What to Add, in What Order

This wiki has 18 guides on testing AI systems, each a deep dive into one technique: unit testing, contract testing, chaos testing, RAG evaluation, agent tool-call testing, and more. If your system has no formal test suite today, that depth is not a syllabus to work through top to bottom. It is a shelf of specialized tools, and picking the wrong one first wastes the scarce engineering time you have.

This page is the sequencing layer. It assumes a system that has been running in production, quietly and successfully, with little or no formal testing beyond manual checks — and that growth (more users, more request volume, more data, more business exposure) is now forcing the question of what to add, in what order. It does not re-explain what any of the 18 guides already cover; it tells you which one to reach for first, second, and third, and argues for why that order beats the alternatives given real constraints. If you are instead building something new and want the build-order framing for a system that doesn’t exist yet, see From zero to production and From localhost to production ; this page assumes the opposite starting point — something that already works.

Why retrofit sequencing is a different problem than greenfield sequencing

A team building a new system can lay down a test pyramid before the first feature ships, because there is no working system yet to disrupt. That is not your situation. Your system already has behavior worth protecting, users who depend on it, and a release cadence that cannot simply stop while a full test suite gets built underneath it. Three constraints shape everything that follows, and they are worth stating explicitly because most testing literature is written for the greenfield case and quietly assumes them away.

Engineering time is scarce and mostly going to features. You cannot ask a two-person team maintaining a working system to build the same test pyramid a fifty-person platform team would run. Every hour spent writing tests is an hour not spent on the roadmap, and that trade has to be justified test by test, not by appeal to “best practice” in the abstract.

Test cost is a recurring operating cost, not a one-time build cost. A test suite that calls a real model API on every CI run accrues API spend on every commit, forever. A system that spins up a full staging environment for every pull request accrues infrastructure cost on every commit, forever. Retrofitting tests without controlling this is how a team ends up with a test suite so expensive to run that people start skipping it — which is worse than not having one, because it creates false confidence.

Risk is not uniform, and coverage should track it, not a generic pyramid shape. A system that generates marketing copy and a system that scores loan applications do not warrant the same test investment at the same point in their growth curve, even at identical user counts. The second should invest in test coverage earlier and go deeper, because the cost of a silent regression is categorically different — the last row of the table below covers the testing consequence of that pressure once regulated data or high business exposure enters the picture.

Given these three constraints, the right question is never “which of the 18 guides should we eventually adopt” — the honest answer to that question is often “most of them, eventually.” The right question is which small set of tests, added first, prevents the worst outcome for the least investment — and what to add next once that floor is in place.

Start with the smallest set of tests that protects what would hurt most

The instinct many engineers bring from conventional software teams is to start at the bottom of the pyramid: write unit tests first, because that is what “properly tested” is supposed to mean. For a system that has been running successfully with no tests at all, this is usually the wrong first move.

Unit tests protect logic. They catch a broken edge case in a function. What they do not catch, on their own, is a broken system — a misconfigured environment variable, a changed API contract with an upstream provider, a deploy that silently drops the connection between two services that individually pass every unit test. For a system that has been running fine for a long time, the near-term risk is not “the chunking function has a subtle bug” — it is “the next deploy breaks something end-to-end and nobody notices until a user complains.” A handful of tests on the critical path catch exactly that, and they catch it regardless of which internal component broke.

So the defensible starting point is: write a small number of end-to-end smoke tests that walk the one or two flows that would hurt most if they silently broke, before investing in comprehensive unit coverage. “Small number” means single digits, not a suite — the user submits the core request, the system responds, the response looks like a real response, not an error page or an empty payload. See End-to-end testing AI-powered products for how to write these, including handling streaming responses and non-deterministic output in the assertions themselves. If the critical path is a web UI, Playwright Testing Guide for AI Applications is the concrete tool guide for setting up the first one or two specs without dragging in a full browser-automation framework you don’t yet need.

This gives the most protection per hour invested for one reason: a smoke test on the critical path fails for almost any category of regression — a broken deploy, a bad config, an upstream outage, a logic bug, a data problem — because it observes the system from the outside, the way a user does. A unit test only fails for the specific thing it was written to check. Early on, when you don’t yet know where the next regression will come from, breadth of detection matters more than precision of diagnosis. You trade “this test tells you exactly what broke” for “this test tells you something broke, before your users do” — and at the start, that trade is the right one.

Then move down the pyramid as change frequency rises

Smoke tests earn their keep by catching catastrophic breakage cheaply, but they are slow, coarse, and expensive to run often — they are not where you want to live once the system is changing several times a week instead of a few times a quarter. As soon as growth means more people touching the code, more frequent deploys, or more complexity in the deterministic logic surrounding the model calls (parsers, prompt assembly, retrieval logic, validation), the economics flip: manually re-verifying that logic on every change now costs more than writing a test for it once.

This is when Unit testing AI applications becomes worth the investment — not on day one, but once the codebase is big enough and changes often enough that a human re-checking it by hand is the more expensive option. Follow it with Integration testing AI pipelines once you have more than one internal service or stage that needs to be verified as a unit, and with CI/CD testing strategy for AI systems to decide which of your growing test set runs on every pull request versus on a schedule — this matters more for a retrofit than a greenfield build, because you are adding CI gates to a pipeline that has been shipping without them and cannot suddenly make every merge take twenty minutes.

Where AI-specific testing enters, and why it is not like testing you’ve done before

Everything above is close to conventional software testing sequencing. AI-specific testing concerns enter at a different point, and they enter for a structural reason: most conventional testing assumes a deterministic function — same input, same output, every time — and asserts exact equality against a known-correct value. A generated response from a model does not have a single correct value. Ask the same question twice and you can get two different, both-acceptable answers. Assert response == "the expected string" against that and the test fails constantly for reasons that have nothing to do with a real defect — which trains the team to ignore failing tests, the single fastest way to make a test suite worthless.

This is why the moment your system calls a model to produce output that a human reads, you need Testing non-deterministic systems in the mix. It replaces exact-match assertions with statistical ones — does the model classify correctly on at least N% of a test set, does a property hold across many generated outputs (response is well-formed JSON, response length stays under a bound, cited sources actually exist in the retrieved context) — rather than checking any single output against a fixed expected string. Testing LLM applications goes further into the LLM-specific surface: prompt templates as testable artifacts, structured-output validation, guardrail verification, and eval frameworks built for exactly this non-exact-match problem.

Two more of the 18 guides apply conditionally, not universally — reach for them only if your system actually has the shape they address, not by default:

• If the system retrieves context before generating a response (RAG), add Testing RAG systems once retrieval quality — not just generation quality — becomes a plausible failure mode worth catching before a user does.
• If the system lets a model call tools or take multi-step actions, add Testing AI agent tool calls once a wrong tool call or a runaway multi-step loop is a realistic, costly failure — not before the system does anything more than a single model call.

The real constraint most guides skip: what tests cost to run

A test suite is not free once it exists — it has a recurring operating cost, and for AI systems that cost is easy to get badly wrong by accident. The single most common mistake in a first retrofit pass is writing tests that call a real model API on every run. That makes CI slow, makes CI cost money on every commit, and makes tests flaky for reasons that have nothing to do with your code (the provider is briefly degraded, a sampled response happens to fall outside your assertion’s tolerance). Mocking AI services for testing is the guide for avoiding this: fixture responses and recorded-response (VCR-style) patterns let your unit and integration tests run deterministically and for free, reserving real model calls for a smaller, explicitly-budgeted eval suite that runs less often. Snapshot testing for AI systems is a related cheap-regression technique worth adding around the same time — it catches unintended changes in output shape or structure without needing a live model call for every comparison.

The same cost discipline applies to environments, not just to API calls. Managing test environments for AI systems covers running a light local or CI-only stack with mocked models before you invest in a full staging environment that mirrors production — which is the retrofit path if you are still on a single environment. If you have not yet split dev/test/staging from production at all, that split is worth making before this section’s environment discipline has much to apply to; Working with multiple environments covers running them well once they exist, and Test data management for AI systems covers building the fixtures and golden datasets those environments and evals both depend on — without which the growing eval suite from the previous section has nothing consistent to run against.

What each stage of growth calls for

There is no single correct order past the first floor described above — the right next guide depends on how much the system has grown, how it has grown, and how much a silent failure would cost. The table below is the practical output of this page: for a given state, which of the 18 testing guides to reach for first, and in what rough order within that stage.

Read the table as a sequence within each row, not as a checklist to complete before moving to the next row. A system can be in the “AI-specific surface area growing” row for its retrieval logic while still only having two or three smoke tests from the first row protecting its critical path — that is normal, and it is fine, as long as the smoke tests exist. The floor from the first row is what makes every later addition safe to build on top of: it is the test that tells you, immediately, if adding all the rest of this broke something.

What “done” looks like for a retrofit

A retrofit test suite is not measured against the 18-guide shelf as a completeness target — a system that never grows into agent tool calls has no reason to ever adopt Testing AI agent tool calls , and that is not a gap. It is measured against the risk it was built to cover: does a regression on the critical path get caught before a user reports it, does a change to the deterministic logic get caught before it ships, and does the test suite itself stay cheap and fast enough that people keep running it rather than routing around it. Revisit the table above whenever the system’s shape changes — a new integration, a new data sensitivity class, a new team member — rather than treating the first pass as final. Left unaddressed, the gap between what a system does and what its tests cover behaves like any other silently accumulating debt; see Managing technical debt in ML systems for how that debt compounds specifically in AI systems, testing included.

Sources

This page is this wiki’s own sequencing methodology for retrofitting tests onto an existing AI system, built to cross-reference the wiki’s 18 existing testing guides rather than to introduce new external claims. No external sources were required beyond those guides themselves.

Further reading

• Testing AI systems : the general testing-pyramid overview this page assumes as background and sequences for a retrofit specifically.
• Working with multiple environments : running split dev/test/staging/production environments well once they exist, which several rows of the table above assume is underway.
• Mocking AI services for testing : the specific technique for keeping a growing test suite from becoming a recurring API bill.
• Managing technical debt in ML systems : what happens when the gap between system behavior and test coverage is left to compound instead of addressed in order.