Assert.that vs Assert.True

Question

gì để thích:

Assert.That(obj.Foo, Is.EqualTo(true)) 

hoặc

Assert.True(obj.Foo) 

Đối với tôi, cả hai đều khẳng định là tương đương, vì vậy mà người ta nên được ưa thích?

Answer 1

Trong trường hợp cụ thể này, không có sự khác biệt: bạn sẽ thấy đầu ra gần bằng cùng một mức độ chi tiết (tức là nó cho bạn biết rằng cái gì đó được mong đợi để đánh giá là true đã được đánh giá là false). Cũng vậy với

Assert.IsTrue(obj.Foo); 

và

Assert.That(obj.Foo, Is.True); 

đội của bạn nên chọn một phong cách khẳng định, và gắn bó với nó trong suốt tất cả các bài kiểm tra của bạn. Nếu nhóm của bạn thích kiểu Assert.That, thì bạn nên sử dụng Assert.That(obj.Foo, Is.True).

Answer 2

Đây là một chút nit-picky nhưng IMHO tôi nghĩ rằng trong trường hợp này Assert.That là không cần thiết tiết và do đó có thể được coi là obfuscation. Nói cách khác, Assert.True sạch hơn một chút, đơn giản hơn và dễ đọc hơn và do đó hiểu được.

Để nhận được nhiều hơn một chút, tôi khuyên bạn nên sử dụng API Assert.IsTrue thay vì Assert.True vì, một lần nữa IMHO, IsTrue "đọc" tốt hơn.

Answer 3

Vì vậy, ok, bạn đã thực hiện bộ thử nghiệm của mình trên máy chủ CI và rất tiếc, một trong số chúng không thành công. Bạn mở các bản ghi và thấy thông báo tiếp theo

BusinessLogicTests.LoginTests.UserAutoLoginTests failed: expected true but was false 

Bây giờ làm thế nào trên trái đất bạn sẽ có được những gì đã xảy ra sai với các bài kiểm tra này, nếu tất cả các thông tin mà bạn nhìn thấy, đó là nơi nào đó trong AutoLoginTests bool đã được dự kiến ​​đúng, nhưng nhận sai? Bây giờ bạn cần phải đi đến tập tin nguồn của các trường hợp thử nghiệm của bạn và xem, những gì khẳng định thất bại. Bạn thấy

Assert.True(obj.Foo) 

Thật ngạc nhiên .. vẫn khó để biết điều gì sai, chỉ khi bạn phát triển mô-đun này 1 giờ trước. Bạn vẫn cần phải thâm nhập sâu hơn vào các nguồn kiểm tra và có thể là nguồn sản xuất hoặc thậm chí gỡ lỗi mã của bạn, để bạn có thể tìm ra lỗi chính tả, hoặc sai chính tả để lọc người dùng đã đăng ký. Do đó, bạn đã chặn phản hồi ngay lập tức từ các thử nghiệm, điều này rất có giá trị. Quan điểm của tôi là không quan trọng việc xác nhận của bạn trôi chảy như thế nào (cũng có liên quan), nhưng thông tin bạn vạch trần trong trường hợp không kiểm tra và bạn có thể nhanh chóng đạt được lý do thất bại như thế nào, ngay cả khi bạn đã làm việc một thời gian dài trước đây với chức năng này

Answer 4

Assert.That được gọi là mô hình dựa trên ràng buộc. Nó linh hoạt bởi vì phương thức lấy tham số của loại IConstraint. Điều này có nghĩa là bạn có thể cấu trúc mã của mình bằng cấu trúc phân cấp hoặc gọi điện thoại chung hơn, đi qua bất kỳ số IConstraint cũ nào. Điều đó có nghĩa là bạn có thể tạo custom constraints

của riêng mình Đó là vấn đề thiết kế. Như mọi người đang nói, không có vấn đề gì bạn vẫn cần phải cung cấp thông tin phản hồi thông báo lỗi phong nha.