Bạn có nên bắt AssertionError trong các bài kiểm tra JUnit không?

Question

Tôi có một đối tượng là kết quả của một cuộc gọi API và tôi muốn xác nhận các giá trị của một biến thành viên.

Giá trị này có thể là một trong hai giá trị được mong đợi tùy thuộc vào những gì cuộc gọi API "nhìn thấy" đầu tiên và đặt trước. Vì vậy, nếu xác nhận trên một giá trị không thành công, tôi muốn xác nhận một giá trị khác trước khi tuyên bố thử nghiệm dưới dạng lỗi.

Cách tốt nhất để làm điều này là gì? Những gì tôi có ngay bây giờ là:

try { 
    assertEquals("message", someObject.getValue1(), expectedValue1); 
} catch(AssertionError ae) { 
    assertEquals("message", someObject.getValue1(), expectedValue2); 
} 

Tôi không chắc liệu đây có phải là thực tiễn có thể chấp nhận hay không. Hãy bình luận.

Answer 1

Sử dụng ngoại lệ như một loại tuyên bố goto được tôn vinh thường không phải là một phương pháp hay. Hoặc ít nhất bạn sẽ gặp phải những người trong sự nghiệp của bạn, người có một cái nhìn mờ nhạt về việc sử dụng các ngoại lệ để kiểm soát luồng chương trình.

Làm thế nào về:

Assert.assertTrue((someObject.getValue1().equals(expectedValue1) || (someObject.getValue2().equals(expectedValue2)); 

Answer 2

tôi sẽ đồng ý với Aquilon liên quan đến thực tế đây không phải là tốt.

Tuy nhiên, bạn có thể sử dụng chế nhạo hoặc một số cơ chế khác để "buộc" API "xem" một mục này trước mục kia không? Bằng cách đó các xét nghiệm của bạn có thể phản ánh các điều kiện dẫn đến một khẳng định là đúng trong một thử nghiệm, và xác nhận khác là đúng trong một thử nghiệm khác.

Answer 3

Phụ thuộc vào mục đích, kiểm tra chức năng tự động hoặc kiểm tra đơn vị. Đôi khi tôi làm điều này cho trước đây:

try { 
    assertTrue(boolean condition from earlier in test method to check); 
} 
catch(AssertionError uhOh) { 
    Logger.err("condition X failed: detailed info msg"); // broken item #1 

} 

try { 
    assertTrue(another condition in same method to check); 
} 
catch(AssertionError yuck) { 
    Logger.err("condition X failed: detailed info msg"); // another broken item 
    fail(); // now blow up as we've checked everything 
} 

Tất nhiên là sử dụng Logger Logger và JUnit's Assert.fail() không thực hiện phương pháp thử nghiệm. Bằng cách này tôi biết tất cả các thất bại cho phương pháp này hơn là thổi lên sau lần đầu tiên. Trong trường hợp của tôi, tôi đang thử nghiệm một ứng dụng web giàu nội dung (hộp thoại và các trang lấy rất nhiều đầu vào của người dùng).

Nhược điểm của "không nhanh" (không sử dụng sản phẩm khai thác) đang tìm một vấn đề, sửa chữa, chạy lại và tìm một vấn đề mới ("rửa sạch và lặp lại"), nhưng nếu được sử dụng để kiểm tra đơn vị thì đây là tài sản với tính mô đun của các bài kiểm tra (lý tưởng là bạn chỉ đang thử nghiệm một khía cạnh của một mục cho mỗi bài kiểm tra).