2011-02-06 42 views
10

tôi tự hỏi, theo quy ước, khi một thử nghiệm thất bại, là nó thích hợp để:JUnit thất bại() ước

  • Say tại sao nó thất bại (business logic)
  • Say tại sao tin nhắn được nhìn thấy (ngoại lệ nên đã được ném ra và nó không phải)

Ví dụ,

fail("Accessed the element which does not exist"); 

hoặc

fail("ArrayIndexOutOfBoundException was expected but something bad happened"); 

Loại nào thường được ưa thích/chấp nhận?

Trả lời

9

Vì đây là mã thử nghiệm và không nên đưa mã vào bản xây dựng cuối cùng, tôi muốn nói chi tiết càng tốt. Như vậy, tôi sẽ đi với cái đầu tiên - rõ ràng hơn nguyên nhân gốc rễ của vấn đề là gì, điều này làm cho việc sửa chữa trở nên dễ dàng hơn.

Tôi muốn tránh trường hợp thứ hai trong mọi trường hợp vì nó không hữu ích cho người kiểm thử, và nếu nó bằng cách nào đó làm cho nó trở thành công cụ xây dựng cuối cùng, khó hiểu hơn người dùng đầu tiên - đơn giản là không trợ giúp cho người thử nghiệm hoặc người dùng.

Một tùy chọn khác mà tôi muốn xem xét thay vì chỉ ra rằng một ngoại lệ đã xảy ra, thay vào đó cung cấp chi tiết về ngoại lệ thực tế - đó là lý do tại sao dấu vết ngăn xếp được phát minh. Điều đó sẽ truyền đạt chi tiết hơn cả hai phương pháp được liệt kê.

+1

tôi thích tên người dùng của bạn quá :) – JAM

4

Nếu có một quy ước về điều này, tôi sẽ bỏ qua nó. Bạn nên nói bất cứ điều gì sẽ tốt nhất giao tiếp với ai đó nhìn thấy thông điệp này bản chất của vấn đề theo cách mà nó có thể được giải quyết dễ dàng nhất có thể. Quá thường xuyên tôn trọng một quy ước không thành công trong vấn đề này.

+0

Nhưng nếu có một quy ước mà ai đó mong đợi bị bỏ qua, nó có thể gây nhầm lẫn.Khi bạn viết một bài kiểm tra, bạn không biết ai có thể nhìn vào nó trong 10 năm. Sau đó, một lần nữa ... trong 10 năm, có thể quy ước đã thay đổi. – dantiston

11

Thứ nhất, nếu bạn mong đợi API bạn kiểm tra để ném một ngoại lệ, thay vì làm một try-catch với một fail() ...

@Test 
public void testMe() { 
    try { 
     api.testThis(); 
     fail("should not reach here"); 
    } 
    catch(MyException e) {} 
} 

... bạn nên làm như sau: -

@Test(expected=MyException.class) 
public void testMe() { 
    api.testThis(); 
} 

Điều đó nói rằng, tôi hiếm khi sử dụng fail(). Nếu tôi cần phải thực hiện xác nhận nhất định và điều kiện thất bại, tôi sẽ khẳng định sử dụng khả năng nhất so với sử dụng fail() ... ví dụ: -

... thay vì ...

@Test 
public void testMe() { 
    boolean bool = api.testThis(); 
    if (!bool) { 
     fail("should be true because bla bla bla"); 
    } 
} 

... làm như sau: -

@Test 
public void testMe() { 
    boolean bool = api.testThis(); 
    assertTrue("bla bla bla",bool); 
} 

Tuy nhiên, nếu bạn thực sự cần phải sử dụng fail(), hãy tiết và giải thích lý do tại sao nó không thành công chứ không phải là "không nên đến đây" hoặc "nên không ở đây" vì điều đó không giúp folks người đọc testcases.

Được cấp, đây chỉ là những ví dụ đơn giản .... nhưng tôi nghĩ tôi đã vượt qua được điểm của mình. :)

+0

Chưa thấy ngoại lệ được mong đợi trong cú pháp chú thích trước đây. Khéo léo. – dantiston

+0

Hãy chú ý đến việc sử dụng chú thích: Nếu phương pháp của bạn có thể ném ngoại lệ với các thông báo lỗi khác nhau hoặc nhiều địa điểm, sẽ tốt hơn nếu bạn sử dụng tính năng thử và so sánh thông báo lỗi. Xem bài đăng trên blog này để biết thêm chi tiết: https://blog.jooq.org/2016/01/20/use-junits-expected-exceptions-sparingly/ –

Các vấn đề liên quan