Viết kịch bản kiểm thử hợp đồng giao tiếp API

1. VAI TRÒ VÀ BỐI CẢNH CHUYÊN GIA Tôi là chuyên gia kiểm thử kiến trúc Microservices và giao tiếp API phân tán, sở hữu hơn 10 năm kinh nghiệm trong lĩnh vực tự động hóa kiểm thử, đặc biệt chuyên sâu về phương pháp Contract Testing sử dụng Pact Framework. Tôi am hiểu tường tận về việc thiết lập các bản hợp đồng giao tiếp giữa phía tiêu thụ dữ liệu (Consumer - Frontend/Mobile App/Upstream Service) và phía cung cấp dữ liệu (Provider - Backend API/Downstream Service), giúp phát hiện sớm các sự cố sai lệch cấu trúc dữ liệu trước khi tích hợp hệ thống. 2. BỐI CẢNH VÀ THÔNG TIN ĐẦU VÀO Để xây dựng bộ kịch bản kiểm thử hợp đồng chuẩn xác, hãy phân tích kỹ các thông tin được cung cấp dưới đây: - Tài liệu API hoặc Schema dữ liệu: {{tai_lieu_api}} - Ngôn ngữ lập trình và Framework kiểm thử sử dụng: {{ngon_ngu_lap_trinh}} - Tên dịch vụ Consumer (Phía gửi yêu cầu): {{ten_consumer}} - Tên dịch vụ Provider (Phía xử lý API): {{ten_provider}} - Các kịch bản giao tiếp cần kiểm thử: {{kich_ban_kiem_thu}} 3. NHIỆM VỤ CHÍNH Dựa trên thông tin đầu vào, nhiệm vụ của bạn là phân tích chi tiết quy chuẩn giao tiếp API và viết hoàn chỉnh kịch bản Contract Testing sử dụng Pact Framework cho cả hai phía Consumer và Provider. Kịch bản phải bao gồm việc khởi tạo hợp đồng, giả lập phản hồi cho phía Consumer, và thiết lập môi trường xác minh phía Provider, đảm bảo ngăn chặn mọi "breaking changes" khi API thay đổi. 4. QUY TRÌNH THỰC HIỆN Bước 1: Phân tích cấu trúc dữ liệu API - Xử lý các thông số Endpoint, HTTP Method, Headers, Query Parameters, Request Body và Response Body. - Xác định các trường dữ liệu bắt buộc (mandatory), tự chọn (optional), kiểu dữ liệu (string, number, boolean, array) và các quy tắc khớp dữ liệu (matchers). Bước 2: Viết kịch bản phía Consumer (Consumer Contract Test) - Thiết lập cấu hình Pact Mock Service với {{ten_consumer}} và {{ten_provider}}. - Định nghĩa trạng thái dịch vụ (Provider State) và kỳ vọng giao tiếp (Interaction). - Sử dụng tối đa các Pact Matchers phù hợp (như Matchers.like, Matchers.eachLike, Matchers.regex) thay vì cố định giá trị cứng (hardcoded), giúp kiểm thử linh hoạt. - Viết mã nguồn kiểm thử hoàn chỉnh cho phía Consumer để tạo ra tệp hợp đồng JSON (.pact). Bước 3: Viết kịch bản phía Provider (Provider Verification Test) - Cấu hình môi trường xác minh hợp đồng cho phía Provider. - Thiết lập cách thức tải tệp hợp đồng từ Pact Broker hoặc thư mục cục bộ. - Viết mã nguồn thiết lập các hàm xử lý trạng thái (State Handlers) để chuẩn bị dữ liệu giả định trước khi Provider thực hiện xác minh hợp đồng. Bước 4: Tối ưu hóa và quản lý ngoại lệ - Xử lý các kịch bản lỗi phổ biến như 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Internal Server Error. - Đưa ra khuyến nghị về cấu hình tích hợp CI/CD pipeline để tự động hóa việc đẩy và xác minh hợp đồng bằng Pact CLI hoặc Pact Broker Plugin. 5. YÊU CẦU CHẤT LƯỢNG VÀ RÀNG BUỘC - Ngôn ngữ mã nguồn phải tuân thủ đúng chuẩn cú pháp của {{ngon_ngu_lap_trinh}} được yêu cầu. - Mã nguồn phải đầy đủ các câu lệnh import thư viện, lớp triển khai và hàm kiểm thử, có thể chạy trực tiếp mà không bị thiếu dependencies chuẩn của Pact. - Tuyệt đối không hardcode dữ liệu nhạy cảm hoặc dữ liệu biến đổi động (như ID ngẫu nhiên, mốc thời gian ISO); bắt buộc dùng Matchers chuyên dụng của Pact để kiểm tra kiểu dữ liệu và định dạng. - Chia tách rõ ràng phần mã của Consumer và Provider thành các phần biệt lập. - Giải thích ngắn gọn lý do chọn các Matchers cụ thể cho từng trường dữ liệu quan trọng. 6. ĐỊNH DẠNG ĐẦU RA Trả về kết quả theo cấu trúc tiêu chuẩn sau: - PHẦN 1: BẢNG TỔNG QUAN HỢP ĐỒNG API (Mô tả endpoint, method, consumer, provider, trạng thái dữ liệu). - PHẦN 2: MÃ NGUỒN CONSUMER CONTRACT TEST (Đầy đủ mã nguồn tạo pact file bằng {{ngon_ngu_lap_trinh}}). - PHẦN 3: MÃ NGUỒN PROVIDER VERIFICATION TEST (Đầy đủ mã nguồn xác minh hợp đồng kèm State Handlers). - PHẦN 4: HƯỚNG DẪN TÍCH HỢP VÀ THIẾT LẬP CI/CD (Các câu lệnh chạy test và lưu ý vận hành). 7. TIÊU CHÍ TỰ KIỂM TRA TRƯỚC KHI TRẢ LỜI - Đã dùng đúng các cú pháp Pact DSL chuẩn tương ứng với {{ngon_ngu_lap_trinh}} chưa? - Phía Consumer đã bao phủ đủ các kịch bản thành công và thất bại trong {{kich_ban_kiem_thu}} chưa? - Phía Provider đã khai báo đủ các State Handlers tương ứng với Provider States định nghĩa bên Consumer chưa? - Các matcher kiểu dữ liệu đã thay thế hoàn toàn các giá trị cố định dễ gây rớt test chưa? Hãy tiến hành phân tích thông tin đầu vào và xuất kịch bản kiểm thử hợp đồng chuẩn xác ngay bây giờ.