Testing an AI Application: What Mocked Tests Prove—and What They Leave Unanswered

Use mocks to make failure cases repeatable

A mocked answer can intentionally cite a foreign source, omit half the input or return an unknown family. Synthetic vectors can reproduce a chain-merging bug exactly. These fixtures are valuable because they isolate backend behaviour from provider variability and allow precise regression checks.

They cannot establish semantic quality. A test supplying the desired answer cannot show that a model would produce it from real evidence. Likewise, a browser test using fixtures can confirm the display and interactions without establishing that the deployed worker, provider and database complete the same task.

Report quality using its denominator

This example calculates a retrieval measure for one synthetic question: how much known relevant evidence appears in the first k results. A real evaluation needs many labelled questions and separate treatment of questions with no supporting evidence.

def recall_at_k(results, relevant, k):
    if not relevant:
        return None  # evaluate unanswerable questions separately
    return len(set(results[:k]) & relevant) / len(relevant)

assert recall_at_k(["a", "x", "b"], {"a", "b"}, 2) == 0.5
assert recall_at_k(["a"], set(), 2) is None

Build an evidence ladder for release decisions

Contract tests should cover ownership, stale sources, retries and restore conflicts. Provider checks should verify configuration, schemas and failure handling with bounded approved data. Reviewer-labelled evaluations should measure retrieval, false merges, missed replies, claim support, abstention and reviewer effort.

Finally, verify the deployed workflow with a known test case: start the job, leave the page, reopen the result and inspect a citation. Passing one layer does not replace the next. When reporting results, name the revision, environment and dataset, and avoid adding overlapping test-run totals into a misleading headline number.