Cộng đồng phát triển phần mềm đang tham gia vào một cuộc tranh luận sôi nổi về các chiến lược kiểm thử, được khơi mào bởi các thảo luận xung quanh việc khi nào và làm thế nào để xóa các bài kiểm thử. Điều bắt đầu như lời khuyên về việc loại bỏ các bài kiểm thử không ổn định và lỗi thời đã phát triển thành một câu hỏi cơ bản: loại kiểm thử nào mang lại giá trị nhất cho các nhóm phát triển hiện đại?
Sự trỗi dậy của những người ủng hộ Integration Test
Ngày càng nhiều nhà phát triển đang thách thức kim tự tháp kiểm thử truyền thống vốn nhấn mạnh unit tests ở tầng cơ sở. Họ lập luận rằng integration tests mang lại giá trị tốt hơn bằng cách kiểm thử cách các thành phần hoạt động cùng nhau trong các tình huống thực tế. Những bài kiểm thử này phát hiện ra các vấn đề mà unit tests bỏ lỡ, chẳng hạn như các vấn đề với tương tác cơ sở dữ liệu, tích hợp API và giao tiếp giữa các thành phần.
Phe ủng hộ integration test chỉ ra rằng một integration test được viết tốt có thể bao phủ nhiều đường dẫn mã mà sẽ cần hàng chục unit tests riêng lẻ. Khi các yêu cầu kinh doanh thay đổi, việc cập nhật một vài integration tests thường dễ dàng hơn so với việc duy trì hàng trăm unit tests mà mock tất cả các dependency.
Thống kê hiệu quả kiểm thử (từ thảo luận cộng đồng):
- Unit testing phát hiện được khoảng 30% lỗi
- Kiểm tra mã nguồn bằng mắt phát hiện được khoảng 70% lỗi
- End-to-end testing phát hiện được khoảng 70% lỗi
- Integration tests thường cung cấp khả năng phát hiện lỗi tốt hơn so với unit tests độc lập
Những người bảo vệ Unit Test giữ vững lập trường
Tuy nhiên, những người ủng hộ unit test lập luận rằng các bài kiểm thử nhanh chóng và tập trung vẫn cần thiết cho quy trình phát triển hiệu quả. Họ nhấn mạnh rằng unit tests xuất sắc trong việc phát hiện các trường hợp ngoại lệ và cung cấp phản hồi nhanh chóng trong quá trình phát triển. Khi một unit test thất bại, các nhà phát triển có thể ngay lập tức xác định hàm hoặc thành phần cụ thể nào có vấn đề.
Unit tests tốt cho việc kiểm thử các đơn vị mã riêng lẻ, integration tests kiểm thử tích hợp. Nếu bạn đợi cho đến khi có đủ mã để kiểm thử tích hợp, khi bạn thực sự viết các bài kiểm thử, bạn sẽ phát hiện ra rằng mình đã check in một loạt mã gần như hoạt động.
Lợi thế về tốc độ của unit tests trở nên đặc biệt quan trọng trong phát triển theo hướng kiểm thử, nơi các nhà phát triển cần phản hồi ngay lập tức để duy trì trạng thái tập trung của họ.
Vấn đề Flaky Test
Cả hai phe đều đồng ý về một vấn đề quan trọng: các flaky tests mà ngẫu nhiên thất bại còn tệ hơn cả việc không có kiểm thử nào cả. Những bài kiểm thử không đáng tin cậy này tạo ra sự tự tin sai lầm khi chúng pass và lãng phí thời gian của nhà phát triển khi chúng fail mà không chỉ ra các vấn đề thực sự. Cộng đồng bị chia rẽ giữa việc sửa chữa flaky tests so với xóa chúng, với nhiều người lập luận rằng sửa chữa phải luôn là lựa chọn đầu tiên.
Một số tổ chức đã tìm ra các giải pháp trung gian, chẳng hạn như tách các flaky tests thành các bộ độc lập chạy ít thường xuyên hơn, hoặc triển khai các cơ chế retry để giảm false negatives trong các pipeline tích hợp liên tục.
Các Vấn Đề Kiểm Thử Phổ Biến Đã Được Xác Định:
- Flaky Tests: Các lỗi ngẫu nhiên làm giảm độ tin cậy của bộ test suite
- Over-Testing: Hơn 150 test cần được cập nhật chỉ vì thay đổi một dòng code
- Slow Test Suites: Các test chạy quá lâu, khiến các developer bỏ qua chúng
- Outdated Tests: Các test không còn phù hợp với yêu cầu kinh doanh hiện tại
- Mock-Heavy Tests: Các unit test có quá nhiều mock đến mức không phản ánh được hành vi thực tế
Tìm kiếm sự cân bằng phù hợp
Các nhà phát triển giàu kinh nghiệm nhất gợi ý rằng việc lựa chọn giữa unit và integration tests phụ thuộc rất nhiều vào codebase cụ thể và bối cảnh nhóm. Các hàm thuần túy với logic phức tạp được hưởng lợi từ unit testing toàn diện, trong khi các hệ thống có tương tác cơ sở dữ liệu nặng hoặc dependencies API bên ngoài thường nhận được giá trị nhiều hơn từ integration tests.
Các nhóm phát triển hiện đại ngày càng áp dụng các phương pháp tiếp cận kết hợp, sử dụng integration tests cho các quy trình người dùng cốt lõi trong khi duy trì unit tests cho logic kinh doanh quan trọng và các trường hợp ngoại lệ. Điều quan trọng là đảm bảo rằng các bài kiểm thử mang lại sự tin tưởng mà không trở thành gánh nặng bảo trì làm chậm quá trình phát triển.
Khuyến nghị Chiến lược Kiểm thử:
- Kiểm thử Nhỏ/Nhanh: Dành cho các commit và phản hồi tức thì
- Kiểm thử Trung bình: Dành cho việc merge và xác thực tích hợp rộng hơn
- Kiểm thử Lớn/Chậm: Để tạo sự tin tưởng khi triển khai production
- Kiểm thử Dựa trên Thuộc tính: Dành cho các thuật toán phức tạp và khám phá các trường hợp biên
- Kiểm thử Hợp đồng: Để đảm bảo các dependency được mock khớp với các implementation thực tế
Kết luận
Cuộc tranh luận về kiểm thử phản ánh các câu hỏi rộng lớn hơn về các thực hành phát triển phần mềm trong thời đại triển khai nhanh chóng và các yêu cầu thay đổi. Mặc dù không có câu trả lời phổ quát, sự đồng thuận của cộng đồng là rõ ràng: các bài kiểm thử tệ còn tệ hơn cả việc không có kiểm thử, và chiến lược kiểm thử tốt nhất là chiến lược mang lại cho các nhà phát triển sự tin tưởng để thực hiện các thay đổi mà không sợ phá vỡ chức năng hiện có.
Khi các thực hành phát triển tiếp tục phát triển, các nhóm phải tìm ra các phương pháp kiểm thử phù hợp với nhu cầu cụ thể, ràng buộc kỹ thuật và văn hóa tổ chức của họ. Mục tiêu không phải là tuân theo một giáo điều kiểm thử cụ thể, mà là xây dựng phần mềm đáng tin cậy phục vụ người dùng một cách hiệu quả.
Tham khảo: You should delete tests