Đổi một trường dữ liệu có thể làm hỏng dịch vụ nào?

Dịch vụ giao hàng đổi trạng thái từ “ready” sang “READY” để thống nhất cách đặt tên. Bản thân dịch vụ vẫn chạy, dữ liệu vẫn là chuỗi và tài liệu mới cũng mô tả đúng. Nhưng ứng dụng theo dõi đơn chỉ biết giá trị cũ, nên không còn hiện nút lấy hàng. Đây là tình huống minh họa cho một thay đổi nhỏ có hậu quả ở nơi khác.

Kiểm thử hợp đồng đưa kỳ vọng của bên sử dụng vào cuộc trao đổi giữa các dịch vụ. Nó trả lời một câu hẹp nhưng quan trọng: phiên bản cung cấp này có đáp ứng những tương tác mà phiên bản sử dụng kia đang dựa vào không?

Hợp đồng bắt đầu từ việc consumer thực sự làm

Consumer không nhất thiết cần mọi trường provider trả về. Ứng dụng theo dõi có thể chỉ cần mã đơn, trạng thái và ngày giao dự kiến. Một hợp đồng hữu ích ghi điều nó cần để ra quyết định, cùng hình dạng yêu cầu mà nó gửi.

Nếu ngày giao chưa biết, trường bị bỏ đi, mang giá trị rỗng hay mang giá trị không có dữ liệu có thể dẫn tới cách hiển thị khác nhau. Đặt những trường hợp ấy thành ví dụ riêng sẽ rõ hơn câu “đầu ra đúng schema”.

Ngược lại, cố định mọi dấu thời gian và mã ngẫu nhiên thành một giá trị duy nhất làm hợp đồng dễ báo sai. Mức khớp cần đủ để bảo vệ hành vi consumer, đồng thời cho provider thay đổi những chi tiết không ảnh hưởng tương tác ấy.

Hai phía phải cùng tạo ra bằng chứng

Ở phía consumer, phép thử xác nhận mã ứng dụng dùng được phản hồi đã thỏa thuận và gửi đúng yêu cầu. Tương tác ấy được giữ thành bản hợp đồng có phiên bản. Một bản hợp đồng viết bằng tay rồi không nối với hành vi consumer có thể nhanh chóng lỗi thời.

Ở phía provider, cần chạy xác minh trên chính dịch vụ hoặc cách triển khai phản ánh hành vi cần kiểm tra. Việc chỉ so hai tệp JSON không cho thấy dịch vụ thật có trả được dữ liệu ở trạng thái tương ứng hay không.

Tài liệu nguồn dùng Pact để minh họa quy trình này. Cách cấu hình phụ thuộc phiên bản công cụ; nguyên tắc ở đây là kết quả của hai phía phải nối được với đúng mã nguồn và đúng tương tác, không chỉ có một tệp mang tên hợp đồng.

Trạng thái provider là phần của bài kiểm tra

“Đơn đang chờ lấy hàng” cần là một điều kiện chuẩn bị được, không phải lời chú thích đứng trên dữ liệu bất kỳ. Phải biết đơn nào tồn tại, ai có quyền đọc và thông tin nào chưa có.

Chuẩn bị từng trạng thái độc lập giúp người chạy không cần dựa vào lần kiểm tra trước. Khi một phép xác minh thất bại, hãy giữ tên trạng thái, yêu cầu, phần phản hồi lệch và bản provider đang chạy. Chỉ ghi “contract failed” khiến hai nhóm lại phải dựng lại toàn bộ câu chuyện.

Tương thích không chỉ là thêm hay xóa trường

Xóa một trường đang được dùng dễ thấy là nguy cơ. Những thay đổi giữ nguyên cấu trúc vẫn có thể phá tương tác: đổi đơn vị, đổi nghĩa trạng thái hoặc biến một giá trị trước đây luôn có thành tùy chọn.

Thêm trường đôi khi không ảnh hưởng consumer, nhưng không thể kết luận luôn an toàn nếu consumer có cách đọc nghiêm ngặt hoặc dùng kiểm tra toàn bộ cấu trúc. Hãy xác minh theo cách consumer thật xử lý, thay vì dùng một danh sách quy tắc tương thích tách khỏi ứng dụng.

Khi cần thay đổi, có thể chọn giai đoạn hỗ trợ cả cũ lẫn mới và theo dõi consumer đã chuyển chưa. Lộ trình cụ thể là quyết định phối hợp của nhóm, không phải điều một kết quả xanh tự làm thay.

Một kết quả xanh có phạm vi phiên bản

Trước phát hành, cần biết hợp đồng nào đã được xác minh với phiên bản nào, thuộc môi trường hoặc nhóm sử dụng nào. Thiếu kết quả không nên được đọc thành đã tương thích; kết quả của consumer cũ cũng không đại diện cho mọi consumer mới.

Kiểm thử hợp đồng không chứng minh luồng giao hàng hoàn chỉnh, hiệu năng hoặc tính đúng của mọi quy tắc nghiệp vụ. Nó giảm một lớp bất ngờ ở ranh giới dịch vụ. Bắt đầu bằng một consumer, một provider và một tương tác gây rủi ro, rồi bổ sung hợp đồng khi có nhu cầu thật để giữ.

Về nguồn tham khảo

Chủ đề tham khảo từ bộ AI Tester Skills. Bài viết và tình huống minh họa được biên soạn lại cho người đọc.