81: Kiểm tra một cách cụ thể và chính xác

Từ lâu việc kiểm tra những hành vi cần thiết, cụ thể của các đoạn code luôn là điều quan trọng, hơn việc kiểm tra những hành vi ngẫu nhiên của chúng bằng một thiết lập cụ thể. Tuy nhiên điều này không nên được thực hiện hoặc nhầm lẫn như một cái cớ cho các kiểm tra mơ hồ. Việc kiểm tra cần phải đúng đắn và chính xác.

Một điều gì đó như là một sự cố gắng, kiểm tra, và kiểm tra cổ điển, thói quen sắp xếp đưa ra các ví dụ minh hoạ. Công việc mỗi ngày của một lập trình viên không nhất thiết là cài đặt thuật toán sắp xếp, tuy nhiên sắp xếp lại chính là một ý tưởng quen thuộc mà nhiều người nghĩ rằng họ biết điều gì đáng để mong đợi. Đây là một điều quen thuộc, tuy nhiên, nó có thể khiến cho việc xem qua một giả định cụ thể gặp khó khăn.

Khi các lập trình viên được hỏi: bạn test đoạn code đó vì điều gì? Cho đến nay câu trả lời xuất hiện thường xuyên nhất chính là “Kết quả của việc sắp xếp chính là một dãy có các phần tử được sắp xếp theo một thứ tự nhất định”. Mặc dù đây là điều chính xác tuy nhiên nó chưa đủ. Khi cài đặt thêm một điều kiện chính xác vào, nhiều lập trình viên thêm vào điều kiện đó là “dãy kết quả phải có độ dài bằng độ dài dãy ban đầu”.Tuy điều trên là đúng nhưng vẫn chưa đủ. Lấy ví dụ, cho một dãy như sau:

3 1 4 1 5 9

Dãy dưới đây thoả mãn các điều kiện đã được đặt ra khi sắp xếp chúng với thứ tự tăng dần và có cùng độ dài với dãy đã cho:

3 3 3 3 3 3

Tuy nó đạt đủ điều kiện đã được đặt ra nhưng nó đã sai với ý định của chúng ta. Đây là một lỗi dựa trên một trường hợp thực tiễn được trích xuất từ code của một sản phẩm (may mắn được phát hiện trước khi ra mắt), điều mà chỉ với một phím nhầm lẫn hoặc điều mà chúng ta đặt ra không đủ chặt dẫn đến một cơ chế phức tạp cho việc lặp lại phần tử đầu tiên của dãy ban đầu trong kết quả. Như vậy điều kiện đầy đủ chính là dãy con phải được sắp xếp theo một thứ tự nhất định đồng thời nó là một chỉnh hợp của dữ liệu nguyên bản. Có như thế chúng mới có thể ràng buộc hành vi cần thiết và khiến cho kết quả lúc nào cũng thật chỉnh chu.

Ngay cả thiết lập dữ kiện cho bài test bằng cách mô tả nó cũng không đủ tốt để trở thành một bài test tốt. Một bài test tốt phải đọc được và đủ đơn giản để bạn có thể dễ dàng xem rằng liệu nó có chính xác hay chưa. Trừ khi bạn đã code một đoạn chương trình để kiểm tra rằng kết quả đã được sắp xếp hay chưa và liệu nó có phải là một chỉnh hợp của dữ liệu ban đầu không. Điều này đơn giản có nghĩa là code dùng để test code sẽ phức tạp hơn nhiều so với code được test như Tony Hoare được chiêm ngưỡng:

“Có 2 cách để xây dựng nên một bản thiết kế phần mềm: một chính là khiến nó trở nên đơn giản đến mức chả còn gì khiến ta phải bận tâm, hai là khiến nó trở nên vô cùng phức tạp đến nỗi hoàn hảo”

Bằng cách áp dụng một vài ví dụ thích hợp chúng ta đã có thể loại bỏ sự phức tạp ngẫu nhiên này, kể cả khả năng xảy ra tai nạn. Ví dụ, cho dãy sau đây:

3 1 4 1 5 9

Kết quả sau khi sắp xếp là:

1 1 3 4 5 9

Nó là duy nhất, không chấp nhận thay thế.

Những ví dụ thích hợp giúp chúng ta minh hoạ chung các hành vi bằng những cách thức dễ tiếp cận và rõ ràng. Kết quả của việc thêm một phần tử vào tập rỗng không phải là phủ định nó. Kết là tập mà bây giờ có một phần tử, chính là phần tử được thêm vào. Thêm vào hai hoặc nhiều hơn các phần tử cũng thoả mãn yêu cầu tuy đúng nhưng chưa đủ. Kể cả thêm một phần tử nhưng có giá trị khác cũng sai nốt. Kết quả của việc thêm một hàng vào bảng không chỉ đơn thuần là bảng đó sẽ lớn thêm một hàng. Nó đồng thời phải đảm bảo giá trị của hàng có thể được sử dụng để tái tạo lại hàng được thêm vào,và tương tự như thế.

Trong việc phân loại hành vi, bài test không chỉ đơn giản là đảm bảo tính đúng đắn mà còn phải đảm bảo sự chính xác.