Dùng test làm bằng chứng

Bắt đầu từ yêu cầu

Test là bằng chứng cho nhận định cụ thể. Lượt test thành công không chứng minh mọi thuộc tính phần mềm. Trước khi yêu cầu test, xác định hành vi quan trọng và lỗi mà mỗi kiểm tra cần phát hiện.

Với tính năng xuất dữ liệu tổ chức giả định, yêu cầu chính là cô lập dữ liệu. Người dùng tổ chức A không được nhận bản ghi tổ chức B. Test chỉ kiểm tra tải thành công không xác lập yêu cầu này.

Yêu cầu agent giải thích quan hệ giữa yêu cầu và assertion. Điều này giúp phát hiện trường hợp còn thiếu trước khi bộ test lớn lên.

Chọn phạm vi test phù hợp

Unit test có thể kiểm tra nhanh phép biến đổi nhỏ. Integration test có thể kiểm tra cách các thành phần làm việc cùng nhau. End-to-end test có thể kiểm tra chuỗi thao tác người dùng quan trọng qua ứng dụng đã triển khai hoặc ứng dụng đại diện.

Dùng phạm vi hẹp nhất cung cấp đủ bằng chứng. Hàm định dạng không cần browser test đầy đủ cho mọi đầu vào. Ranh giới phân quyền có thể cần route và đường truy cập dữ liệu thật. Tương tác trình duyệt quan trọng cần bằng chứng về giao diện đã render.

Không tỷ lệ cố định nào giữa các loại test phù hợp mọi hệ thống. Chọn theo lỗi cần phát hiện và chi phí duy trì kiểm tra.

Tránh cùng chia sẻ giả định sai

Agent có thể viết mã và test từ cùng hiểu lầm. Cả hai có thể khớp nhau trong khi yêu cầu vẫn chưa được đáp ứng.

Giả sử mã lọc bản ghi theo ID tổ chức được cung cấp trong request. Test dùng cùng ID cho người dùng đăng nhập và request. Test đạt. Trường hợp thiếu là người dùng yêu cầu ID của tổ chức khác.

Thêm trường hợp đó qua danh tính đáng tin cậy và luồng phân quyền thực tế. Mock luôn trả “được phép” không thể chứng minh cô lập tenant. Nó chỉ xác lập hành vi sau khi phân quyền cho phép.

Xác minh test có thể thất bại

Với lỗi đã biết, chạy regression test mới trên phiên bản có lỗi trong branch cô lập. Xác nhận thất bại vì lý do dự kiến. Sau đó áp dụng bản sửa và chạy lại.

Test thất bại vì fixture không tải được chưa phải bằng chứng về hành vi nghiệp vụ. Kiểm tra lỗi thất bại, không chỉ exit code.

Với thay đổi rộng hơn, mutation testing có thể giúp đánh giá liệu các thay đổi mã được chọn có làm test thất bại không. Nó có chi phí và không thay thế review yêu cầu. Dùng khi bằng chứng thêm hỗ trợ quyết định có hậu quả đáng kể.

Giữ bằng chứng gắn với thay đổi

Chạy kiểm tra liên quan trên bản sửa cuối. Ghi kiểm tra bị bỏ qua và lý do. Kết quả từ commit trước có thể không còn áp dụng sau sửa theo review.

Giữ test dễ hiểu. Ưu tiên thiết lập và assertion rõ ràng hơn helper lớn che khuất điều kiện quan trọng. Bỏ kiểm tra dư thừa khi chúng tăng chi phí bảo trì mà không phát hiện lỗi khác.

Người review cần nói được test chứng minh gì và điều gì còn chưa chắc chắn. Giải thích đó hữu ích hơn số lượng test lớn.