Tại sao JUnit chạy các trường hợp kiểm tra cho Lý thuyết chỉ cho đến khi thất bại đầu tiên?

Question

Gần đây, một khái niệm mới về Theories đã được thêm vào JUnit (kể từ v4.4).

Tóm lại, bạn có thể đánh dấu phương pháp thử nghiệm của bạn với @Theory chú thích (thay vì @Test), làm cho phương pháp thử nghiệm của bạn parametrized và khai báo một mảng các tham số, được đánh dấu bằng @DataPoints chú thích ở đâu đó trong cùng một lớp.

JUnit sẽ chạy tuần tự phương pháp kiểm tra tham số của bạn khi truyền các tham số được truy xuất từ ​​@DataPoints cái khác. Nhưng chỉ cho đến khi lời kêu gọi đầu tiên thất bại (do bất kỳ lý do gì).

Khái niệm này có vẻ rất giống với @DataProviders từ TestNG, nhưng khi chúng tôi sử dụng nhà cung cấp dữ liệu, tất cả các trường hợp đều chạy thử nghiệm kết quả thực hiện của chúng. Và nó hữu ích bởi vì bạn có thể xem có bao nhiêu công việc quan sát/không hoạt động và bạn có thể sửa chương trình của mình hiệu quả hơn.

Vì vậy, tôi tự hỏi lý do nào không thực hiện phương pháp được đánh dấu là @Theory cho mỗi @DataPoint? (Nó xuất hiện không quá khó khăn để thừa kế từ Á hậu lý thuyết và làm cho một Á hậu tùy chỉnh mà sẽ bỏ qua thất bại nhưng tại sao chúng ta không có hành vi như vậy ra khỏi hộp?)

UPD: Tôi đã tạo ra một lỗi khoan dung phiên bản của Lý thuyết Á hậu và cung cấp cho truy cập công khai: https://github.com/rgorodischer/fault-tolerant-theories

Để so sánh nó với tiêu chuẩn Lý thuyết chạy runner StandardTheoriesBehaviorDemo được đặt dưới thư mục src/test/....

Answer 1

AFAIK, ý tưởng cũng giống như với xác nhận, lỗi đầu tiên dừng thử nghiệm. Đây là sự khác biệt giữa Tham số & Lý thuyết.

Tham số mất một tập hợp các điểm dữ liệu và chạy một tập hợp các phương pháp thử nghiệm với từng điểm. Các lý thuyết cũng giống nhau, nhưng thất bại khi khẳng định đầu tiên thất bại.

Hãy thử xem Parameterized. Có lẽ nó cung cấp những gì bạn muốn.

Answer 2

Báo cáo nhiều thất bại trong một thử nghiệm đơn thường là dấu hiệu cho thấy thử nghiệm không quá nhiều so với thử nghiệm đơn vị phải làm. Thông thường, điều này có nghĩa là thử nghiệm thực sự là một thử nghiệm chức năng/chấp nhận/khách hàng hoặc, nếu đó là thử nghiệm đơn vị thì là thử nghiệm đơn vị quá lớn.

JUnit được thiết kế để hoạt động tốt nhất với một số thử nghiệm nhỏ. Nó thực hiện từng thử nghiệm trong một cá thể riêng biệt của lớp thử nghiệm. Nó báo cáo lỗi trên mỗi bài kiểm tra. Mã thiết lập được chia sẻ là tự nhiên nhất khi chia sẻ giữa các lần kiểm tra. Đây là một quyết định thiết kế thấm vào JUnit, và khi bạn quyết định báo cáo nhiều thất bại cho mỗi thử nghiệm, bạn bắt đầu chiến đấu chống lại JUnit. Điều này không được khuyến khích.

Kiểm tra dài là mùi thiết kế và cho biết khả năng thiết kế vấn đề. Kent Beck thích nói trong trường hợp này là "có một cơ hội để tìm hiểu điều gì đó về thiết kế của bạn."Chúng tôi muốn thấy một ngôn ngữ mô hình phát triển xung quanh những vấn đề này, nhưng nó đã không chưa được viết ra Nguồn:. http://junit.sourceforge.net/doc/faq/faq.htm#tests_12

Để bỏ qua thất bại khẳng định bạn cũng có thể sử dụng một JUnit quy tắc thu lỗi:

Nguyên tắc ErrorCollector cho phép thực hiện một thử nghiệm để tiếp tục sau khi vấn đề đầu tiên được tìm thấy (ví dụ, để thu thập tất cả các sai hàng trong một bảng, và báo cáo tất cả chúng cùng một lúc)

012.

Ví dụ: bạn có thể viết một thử nghiệm như thế này.

public static class UsesErrorCollectorTwice { 
    @Rule 
    public ErrorCollector collector= new ErrorCollector(); 

    @Test 
    public void example() { 
    String x = [..] 
    collector.checkThat(x, not(containsString("a"))); 
    collector.checkThat(y, containsString("b"));    
    } 
} 

Bộ thu thập lỗi sử dụng bộ ghép khớp. Tùy thuộc vào sở thích của bạn, điều này là tích cực hay không.

Answer 3

Lý thuyết sai nếu một thử nghiệm trong đó sai, theo định nghĩa của Lý thuyết. Nếu các trường hợp thử nghiệm của bạn không tuân thủ quy tắc này, sẽ là sai khi gọi chúng là "Lý thuyết".