Contract testing là gì, khác gì Integration testing

💡 Hiểu "hợp đồng" bằng ví dụ cụ thể

Hãy hình dung đội Frontend và đội Backend cùng ngồi thống nhất trước: khi gọi GET /v1/orders/{orderId}, response sẽ luôn có đúng các field này, đúng kiểu này. Bản thống nhất đó — thường được viết ra thành 1 file schema (OpenAPI/Swagger, hoặc file Pact) — chính là "hợp đồng":

// "Hợp đồng" cho GET /v1/orders/{orderId} — cả 2 đội cùng đồng ý
{
  "orderId": "string",       // bắt buộc có
  "customerId": "string",    // bắt buộc có
  "status": "PAID | PENDING | CANCELLED",  // chỉ 1 trong 3 giá trị này
  "total": "number"          // bắt buộc là số, không phải chuỗi "350000"
}

Từ bản hợp đồng này, mỗi bên tự kiểm tra phần của mình tách rời nhau, không cần chạy cùng lúc:

• Phía Consumer (frontend, hoặc service khác gọi API này): viết test khẳng định "tôi trông đợi response đúng như hợp đồng" — chạy được ngay cả khi Backend chưa code xong, vì không gọi API thật.
• Phía Provider (backend cung cấp API): sau khi code xong, tự gọi API thật của mình 1 lần rồi so response thực tế với đúng hợp đồng đó — nếu sau này backend lỡ đổi total từ số thành chuỗi, hoặc đổi tên field, test sẽ báo đỏ ngay lập tức.

Cả hai không cần đứng chờ nhau chạy chung một lúc — chỉ cần cùng nhìn vào một bản hợp đồng làm "trọng tài". Đây là lý do contract test chạy nhanh như unit test (Tầng 1 — Chương 7), trong khi Integration testing (Chương 3) bắt buộc phải khởi động cả 2 hệ thống thật rồi mới gọi thử được.

📌 Ghi nhớ

Contract testing không thay thế Integration testing — 2 loại bổ sung cho nhau: contract testing bắt lỗi "sai cấu trúc" sớm và rẻ, integration testing bắt lỗi "sai hành vi" toàn diện hơn nhưng tốn kém hơn.