AI Wisdom
accepted2026-04-08

ADR-011: Testing Strategy for LLM-Powered Features

In this article

Context

Traditional unit and integration tests are insufficient for AI features because LLM outputs are non-deterministic. We need a testing strategy that gives us confidence in AI feature quality without requiring expensive human review of every change.

Options Evaluated

Manual Testing Only

Pros
  • +Simple โ€” no test infrastructure required
  • +Captures nuanced quality issues
  • +Appropriate for early prototypes
Cons
  • โˆ’Does not scale โ€” every prompt change requires manual re-review
  • โˆ’No regression detection for prompt or model changes
  • โˆ’Quality is subjective and inconsistent across reviewers

Automated Evals with LLM-as-Judge

Pros
  • +Scalable โ€” evaluate hundreds of test cases in minutes
  • +Runs in CI/CD โ€” blocks regressions automatically
  • +LLM judge scores quality dimensions (faithfulness, relevance, safety) systematically
Cons
  • โˆ’LLM judge has its own biases and is not perfectly calibrated to human preferences
  • โˆ’Requires investing time in building good eval datasets
  • โˆ’Cost: eval suite run = N test cases ร— evaluator LLM cost

Snapshot Testing for Prompts

Pros
  • +Catches unintended prompt changes
  • +Fast โ€” no LLM calls required for snapshot verification
  • +Familiar pattern from UI testing
Cons
  • โˆ’Frozen snapshots do not test quality โ€” only that output is unchanged
  • โˆ’Brittle โ€” non-determinism causes snapshot failures

Hybrid: Unit + Evals + Production Sampling

Pros
  • +Unit tests for deterministic components (prompt templates, parsers, validators)
  • +Evals for output quality dimensions
  • +Production sampling for real-world quality monitoring
Cons
  • โˆ’Most complex to set up โ€” three test types to maintain
  • โˆ’Requires eval dataset curation investment upfront

Decision

We adopt the Hybrid approach. (1) Standard unit tests for all non-LLM components โ€” prompt template rendering, response parsers, guardrail logic, schema validation. (2) LLM-as-judge eval suites (RAGAS + DeepEval) run in CI for every prompt or model change, with quality thresholds enforced. (3) 5% production sampling with Phoenix online evals for continuous quality monitoring.

Consequences

  • โ€ขCreate eval dataset for each AI feature โ€” minimum 20 test cases per feature
  • โ€ขIntegrate DeepEval or RAGAS into CI pipeline with automated quality gates
  • โ€ขDefine per-feature quality thresholds (e.g., RAG faithfulness > 0.85, relevance > 0.80)
  • โ€ขLog 5% of production LLM calls to Phoenix for online evaluation
  • โ€ขSet up weekly AI quality review process to review flagged responses

Discussion

Sign in to share your feedback and join the discussion.