LLM Testing
LLM testing checks that a model-powered application meets its functional contracts and handles known failure cases. It combines deterministic software tests with task-level evaluation of probabilistic outputs, so schema correctness, tool behavior, regression risks and answer quality are examined through methods appropriate to each property.
What it is
Some application behavior is deterministic: a parser must reject invalid records, a tool must enforce access and a retry policy must not duplicate a write. Other behavior depends on model generation and needs repeated or rubric-based assessment. Testing therefore spans unit checks for components, integration checks for data flow and evaluation cases for output quality. It differs from general benchmarking because it targets a particular application contract. Exact text equality is often unsuitable for valid paraphrases, while a vague semantic judgment is insufficient for identifiers, permissions or executable effects that can be checked directly.
What the work involves
The practitioner maps requirements to tests and keeps model-independent checks fast and strict. Representative evaluation cases cover expected behavior, insufficient evidence and difficult edge cases. Tests record model and prompt versions, with repeated trials where variation matters. Useful artifacts include component tests, integration fixtures and a regression collection tied to past failures. Mocked responses help exercise client code but do not validate the actual model. Release reports distinguish software checks from probabilistic quality measurements and state which failures block deployment.
Illustrative example
A scheduling assistant generates a structured booking proposal. Unit tests verify date parsing and authorization, integration tests verify the tool call lifecycle, and model tests check whether varied user requests yield the correct proposed time. An ambiguous timezone case should request clarification. A response with the correct schema but the wrong date fails the task test. A perfectly worded answer that bypasses the booking permission fails the application contract regardless of a model judge's preference.
Limits and common mistakes
A passing mocked suite can hide model failures, while a small output sample can hide intermittent regressions. Snapshot tests may also overconstrain harmless wording changes. Tests need clear property definitions and representative cases, including failures introduced by external services. LLM testing is most useful when each layer uses the strongest available check and when final task outcomes remain visible rather than being inferred from successful API calls or valid formatting.
Prerequisites
Schema adherence tests validate that LLM outputs match expected JSON schemas — structured output understanding is required
- mediumML CI/CD
LLM system tests are typically run within CI/CD pipelines — understanding CI/CD helps integrate tests into workflows
Related skills
- ← is part of: AI Output Verification
- ← is part of: LLM Evaluation Design
- → is part of: MLOps
- ← is part of: Stochastic System Debugging
Sources and further reading
- Evaluation best practices
Supports application-specific cases, regression evaluation and explicit scoring criteria.
- LangSmith evaluation
Documents executing and comparing application evaluations over datasets.
Last updated: 2026-10-10