Nguyên tắc 4: Test-Protected
Test là hàng rào để AI được phép viết lại mà không làm lệch hành vi.
Test trong SDD nên kiểm tra HÀNH VI từ spec, không chỉ kiểm tra chi tiết triển khai.
Tình huống
- Team Nam (200+ test bám AC): Claude đề xuất refactor sang strategy pattern → 196 pass, 4 fail. Đọc kỹ: 2 test cũ mock quá sát implementation (cần sửa), 2 test bắt đúng regression. Sửa rồi merge tự tin.
- Team khác (12 smoke test kiểu “API trả 200”): refactor, test pass hết, tuần sau production incident vì rule “không refund cho một nhóm khách” đã biến mất. Test không bắt được vì nó chưa bao giờ kiểm rule đó.
Khác biệt không nằm ở số lượng test, mà ở việc test có bám vào Acceptance Criteria hay không.
Cách áp dụng
Cấu trúc test soi chiếu spec:
tests/use-cases/UC-042-place-order-qr/
AC-1-create-qr.test.ts
AC-2-payment-success.test.ts
AC-3-qr-expired.test.ts
AC-4-idempotency.test.ts
- Mỗi AC ≥ 1 test; tên test/annotation chứa UC ID + AC ID:
describe("UC-042 / AC-2: payment success")hoặc@UseCase("UC-042"). - Test đầu tiên cho một pattern nên do người viết hoặc review kỹ, sau đó AI mới clone pattern. Đừng để AI tự viết code rồi tự viết test cho chính code đó mà không có điểm tựa từ spec (→ an toàn giả).
Liên quan
- Sáu nguyên tắc Spec-Driven - nguyên tắc số 4
- Acceptance Criteria - test map 1-1 với AC
- Characterization Test - dạng test đặc biệt cho legacy
- Chỉ số đo SDD - AC Coverage & Regen Success Rate