Thông báo xác nhận: giả sử thất bại hoặc giả định thành công

Question

Khi thử nghiệm bằng bất kỳ ngôn ngữ nào, mọi người cụm từ thông báo xác nhận của họ như thế nào?

tôi thấy ba cách rõ ràng:

# assume failure 
assert (4-2) == 2, "Subtracting 2 from 4 doesn't equal 2" 

# describe success 
assert (4-2) == 2, "Subtracting 2 from 4 should equal 2" 

# be vauge with failure 
assert (4-2) == 2, "Subtracting 2 from 4 is broken" 

Điều này rõ ràng là một ví dụ đơn giản, nhưng bạn sẽ có được ý tưởng. Thực hành tiêu chuẩn là gì? Bạn làm nghề gì? Tại sao?

Answer 1

Điều quan trọng với khẳng định là điều kiện thực tế đang được kiểm tra. Trong C, bạn có thể sử dụng "xử lý chuỗi" tiền xử lý để đưa ra điều kiện thực tế đang được kiểm tra. Mã của tôi chỉ kết quả đầu ra

Assert Failed: (4-2)==2 : Line 123, File foo.c 

Nếu bạn may mắn, bạn có thể nhận được một chồng đổ cũng ...

Answer 2

Nó thực sự không quan trọng IMO, miễn là thông báo lỗi cho bạn biết những gì đã đi sai và vấn đề ở đâu. Trong hoạt động bình thường, một thông báo khẳng định sẽ không bao giờ được nhìn thấy. Nếu nó được nhìn thấy, có một lỗi trong mã một nơi nào đó, và bạn cần để có thể theo dõi và sửa lỗi.

Thư phải cung cấp càng nhiều thông tin hữu ích càng tốt - nếu bạn kiểm tra hai giá trị đó bằng nhau và không, bạn nên in ra giá trị là gì. Điều đó làm giảm bớt sự cần thiết phải bước vào nó với một trình gỡ lỗi để kiểm tra các giá trị. Tất nhiên, làm điều này đòi hỏi rằng ngôn ngữ của bạn hỗ trợ thông tin không tĩnh trong các thông báo xác nhận. Nếu các thông báo xác nhận chỉ có thể được sửa, các chuỗi tĩnh, bạn không thể thêm thông tin thời gian chạy bổ sung mà không cần nhảy qua các vòng lặp.

Answer 3

Tôi không biết thực hành tiêu chuẩn là gì, nhưng tôi kết hợp hai phương pháp đầu tiên của bạn với việc bổ sung kết quả thực tế thu được.

 
"Substracting 2 from 4 should equal 2, but equals " + value 

Điều này không còn chỗ cho nghi ngờ và giảm bớt gỡ lỗi.

Answer 4

Đề xuất của Roddy là một gợi ý tốt - chắc chắn làm cho "chi phí" thêm xác nhận mới rẻ hơn nhiều (tức là không yêu cầu phải suy nghĩ hoặc nhập thông báo chuỗi mới). Tin hay không, nhưng việc thực hiện đề xuất của ông đã có tác động đáng kể đến việc tôi sử dụng các xác nhận.

Nếu bạn vẫn đang tìm kiếm một tin nhắn văn bản rõ ràng, tuy nhiên, bạn có thể xem xét một cái gì đó như:

"Dự kiến ​​4-2 để bằng 2"

Điều này dường như làm cho rõ ràng (ít nhất là tới tôi) rằng câu trả lời mong đợi là 2, nhưng mong đợi không được đáp ứng ...

Answer 5

Tôi không biết nếu có bất kỳ "tiêu chuẩn" nào, nhưng trong hầu hết các trường hợp, tôi muốn tự mình thấy điều kiện xác nhận. C thực hiện điều này tự động. Trong C# tôi phải sao chép-dán nó, thật không may, ví dụ như.

Debug.Assert(4-2==2, "4-2==2");

Trong một số trường hợp nó là hữu ích để xem chi tiết thông tin hơn điều kiện cung cấp. Trong trường hợp đó, tôi xử lý thông báo xác nhận như một thông báo lỗi và nêu rõ điều gì sai, ví dụ.

Debug.Assert(result != null, "No result returned for input '" + input + "'");

Answer 6

tôi sử dụng thông điệp khẳng định để tài liệu những gì khẳng định là thử nghiệm, hoặc những gì giá trị kỳ vọng là về.

Đôi khi, khi thử nghiệm không thành công, tôi không cần phải xem xét thử nghiệm không thành công: chỉ từ thông báo xác nhận và thay đổi mà tôi vừa tạo, tôi biết cách khắc phục.

Answer 7

Tôi xử lý các thông báo xác nhận như bình luận: Tôi cố gắng không có chúng nếu tôi có thể tránh nó, nếu tôi có thể làm cho ý định rõ ràng từ mã.

Thông thường đây là vấn đề khi có một số thuộc tính bạn muốn xác nhận có liên quan theo một cách nào đó. Việc trích xuất các xác nhận vào một phương thức được đặt tên để chỉ ra khía cạnh/mối quan hệ bạn quan tâm làm cho nó rõ ràng hơn những gì đang diễn ra mà không có chi phí duy trì nhận xét/tin nhắn.