95: Viết Tests Cho Mọi Người

Bạn đang viết các bài kiểm tra tự động cho các bài code của bạn. Xin chúc mừng! Bạn viết các bài kiểm tra đó trước khi viết code? Điều này thậm chí còn tốt hơn! Việc này sẽ giúp bạn trở thành một trong những người chấp nhận công nghệ tiến gần hơn với thực hành kỹ thuật phần mềm. Nhưng bạn đã viết tests tốt chưa? Bạn có thể thể hiện như thế nào? Cách duy nhất là hãy tự hỏi “Mình đang viết tests cho ai?” Nếu câu trả lời là “Cho chính mình, để giảm bớt việc sửa lỗi ấy mà” hay “Cho trình biên dịch, để chúng có thể hoàn thiện hơn” và điều kỳ quái là bạn chẳng viết tests tốt nhất có thể. Vậy bạn nên viết tests cho ai? Cho những người cố gắng hiểu code của bạn.

Những tests tốt đóng vai trò như là một tài liệu tham khảo cho bài code mà họ đang kiểm tra. Họ mô tả quá trình làm việc của mã code, cho từng trường hợp sử dụng bộ test:

• Mô tả bối cảnh, điểm bắt đầu hay điều kiện thích hợp.
• Minh họa phần mềm được hoạt động như thế nào.
• Mô tả kết quả hay điều kiện xác định sau cùng.

Trường hợp sử dụng khác nhau sẽ cho ra các kết quả tương đối khác nhau. Người cố gắng để hiểu code của bạn phải có khả năng tìm hiểu số ít các tests và nghi vấn so sánh ba phần trên của các tests với nhau, có khả năng thấy được điều gì làm cho phần mềm hoạt động khác biệt. Mỗi test phải được minh họa rõ ràng mối liên hệ nguyên nhân-kết quả giữa ba phần của nó. Điều này có nghĩa rằng những thứ không hiện hữu trong test cũng quan trọng không kém. Code quá nhiều làm cho người đọc trở nên mất tập trung bởi những chi tiết nhỏ nhặt không quan trọng. Bất cứ khi nào có thể ẩn đi những chi tiết nhỏ nhặt và sử dụng hàm để gọi lại chúng- việc tái cấu trúc lại bằng Extract Method sẽ giúp bạn rất nhiều. Và chắc chắn rằng bạn đặt tên thể hiện được cụ thể trường hợp sử dụng cho test để người đọc chẳng cần phải dò lại để nhớ lại từng trường hợp đó là gì. Giữa chúng, tên của test class và class method nên bao gồm ít nhất điểm bắt đầu và cách phần mềm hoạt động. Điều này cho phép toàn bộ test được xác nhận thông qua một lần quét nhanh các tên của method. Cũng có ích khi bao gồm cả kết quả mong đợi vào tên của bộ kiểm tra method miễn là điều này không làm cho cái tên quá dài.

Kiểm tra tests của bạn là một ý tưởng hay. Bạn có thể xác nhận cách chúng phát hiện ra các lỗi mà bạn nghĩ rằng chúng phát hiện lỗi bằng cách thêm nó vào code sản xuất (một bản sao chép riêng của bạn mà bạn tất nhiên sẽ không vứt đi). Hãy chắc chắn chúng sẽ báo cáo lỗi một cách có ích và có nghĩa. Bạn cũng nên chắc chắn rằng người đọc sẽ hiểu được rõ ràng tests của bạn. Cách duy nhất để thực hiện được điều đó là nhờ một ai không biết gì về code của bạn đọc tests và kể lại những gì họ học được. Hãy lắng nghe cẩn thận những gì họ nói. Nếu họ không thiểu thứ gì đó rõ ràng, điều đó có lẽ không phải vì họ không sáng suốt. Nhiều khả năng là do bạn viết không rõ ràng.

(Được rồi, hãy đổi vị trí — bạn sẽ đọc các tests của họ!)