Goal of unit test

Một thời gian test-first, đã kiểm chứng được một số vấn đề. Đặc biệt nhất là mục tiêu của unit test.

Trước hết unit test là một cách đáp ứng cho lập trình có chủ đích (intentional programing, theo cách nói của Robert C Martin). Khi nhận một user story, tôi thử không vạch ra hết cách tính huống để design. Trước tiên, tìm một metaphor cho nó. Từ metaphor suy diễn nhanh một overview design; sau đó bắt đầu viết các client code (cũng chính là unit test) là cái cách mà mình mong muốn product code sẽ đáp ứng. Sau đó nghĩ bắt đầu viết product code để vượt qua unit test. Refactoring. Viết unit test. Refine design. Viết product code. Refactoring .... Cách này hơi lazy một chút, nhưng design cứ xuất hiện một cách rất tự nhiên. Có lúc buộc phải nghĩ đến pattern để giải quyết nhưng có lúc mình áp dụng các pattern lúc nào không hay. Khi này mới thấy các pattern rất tự nhiên và hữu dụng. Cách lazy này có nhược điểm là hơi chậm, nhất là khi phải làm một mình, không có partner để phản biện :(. Hèn gì "lòi" ra cái pair-programing.

Unit test còn là một công dụng đắc lực cho refactoring; nhất là giai đoạn refine lại design. Ngày trước, khi không có unit test, tôi rất ngại phải refactor bởi vì không biết rằng những chỉnh sửa ở đoạn code này có ảnh hưởng đến đoạn code khác hay không. Unit test bảo đảm cho tôi chuyện này. Refactor và chạy lại unit test, nếu tất cả đều pass thì an tâm :).

Unit test là một document tuyệt vời. Chúng là các source-code mẫu hướng dẫn cách sử dụng các api; đơn giản bởi vì chúng đang sử dụng các api. Có cái hơi bất tiện là người đọc phải học cách đọc một test case, nhưng là chuyện nhỏ với ai ham học ;).

Ít lý thú nhất là xem unit test là một cách để có "program by contract". Dùng unit test các giá trị vi phạm pre-condition để biết chắc phản ứng của source-code. Sau đó test các giá trị thỏa pre-condition và kiểm tra post-condition. Cách viết này khiến unit-test trở thành một thứ nhàm chán cực kỳ. Chỉ có pair mới giúp giảm mức nhàm chán :(.