80: Test for Required Behavior, not Incidental Behavior

Một điều đáng tiết thường xảy ra trong việc kiểm thử chính là dự đoán tất cả những gì mà mà một chương trình làm một cách chính xác với bộ thử của bạn. Nhìn sơ qua thì nó chả giống như một điều gì đáng tiếc cả. Tuy nhiên, ở một góc độ khác, vấn đề trở nên rõ ràng hơn: một điều đáng tiết trong testing thường xảy ra chính là kiểm tra một cách cứng nhắc đến một điều đặc biệt của chương trình mà chúng lại không quan trọng cũng như không thể hiện được tính năng mong muốn của chương trình.

Khi bài test được viết tràn lan, tự động, những thay đổi tác động đến chúng để thích hợp với những trường hợp chính khiến chúng không chính xác hoặc phát sinh những cảnh báo giả. Để đáp lại chúng, lập trình viên sẽ sửa lại code hoặc bộ test ấy. Tuy nhiên nếu như báo động ấy là thật thì nó chính là hậu quả của nỗi sợ hãi, không chắc chắn, hoặc nghi ngờ. Điều này khiến cho những trường hợp phát sinh xảy ra nhiều hơn. Khi viết lại một test mới, lập trình viên chúng ta hoặc tập trung vào những trường hợp chính, thông dụng( tốt) hoặc đơn giản ràng buộc nó bằng cài đặt mới (không tốt).

Những bộ test không chỉ phải đúng mà còn phải thật chính xác.

Lấy ví dụ, trong một sự so sánh có 3 kết quả, nhứ là hàm strcmp của ngôn ngữ C hay String.compareTo của ngôn ngữ Java. Những yêu cầu của kết quả chính là trả về -1 nếu bên trái lớn hơn bên phải, 1 nếu như bên phải lớn hơn bên trái và 0 nếu 2 bên bằng nhau. Kiểu so sánh này được dùng trong nhiều API, kể cả phép so sánh trong qsort của C và compareTo của Java. Mặc dù giá trị -1 và 1 thường dùng để phân biệt nhỏ hơn hay lớn hơn, nhưng các lập trình viên thường nhầm lẫn cho rằng những giá trị này là mới chính là yêu cầu của bài toán từ đó viết những bộ test chung dựa trên lầm tưởng ấy.

Một vấn đề tương tự trong việc test đó chính là những đòi hỏi về khoảng cách, từ ngữ, và những khía cạnh khác của định dạng và biểu diễn văn bản là không là không cần thiết. Trừ khi bạn đang viết, ví dụ, một chương trình sinh file XML mà yêu cầu chỉnh sửa định dạng và khoảng cách là không đáng kể. Tương tự như thế, đặt nút nhấn và nhãn tuân thủ những quy tắc UI có thể giảm khả năng để thay đổi và tái thiết lập chúng trong tương lai. Những thay đổi nhỏ trong quá trình cài đặt hoặc những thay đổi ngẫu nhiên do phát sinh đột nhiên trở thành kẻ phá hoại.

Những bài test được tinh chỉnh quá mức sẽ xảy ra vấn đề hộp trắng(White Box) khi tiến tới unit testing. Những bài test hộp trắng sử dụng cấu trúc của đoạn code để quyết định những trường hợp nào dùng để test. Sự thất bại điển hình nhất chính là khiến cho đoạn code thực hiện việc nó thực hiện. Điều này đơn giản tái khởi động tất cả mọi thứ, đoạn công không tạo giá trị nào và dẫn đến những sai lầm trong quá trình phát triển và bảo mật.

Cuối cùng, chúng ta không thể đạt được sự hiệu quả nếu cài đặt những bộ test như một con vẹt. Vấn đề phải được nhìn nhận dưới góc nhìn hộp đen(black box) của từng đơn vị test, phác thảo những liên kết bằng hình thức thực thi. Từ đó, điều chỉnh bộ test theo những hành vi được yêu cầu của đoạn code.