jUnit fail() konwencje

Question

Zastanawiam się, zgodnie z przyjętą konwencją, gdy próba nie powiedzie się, to za stosowne:

• powiedzieć, dlaczego nie udało (logiki biznesowej)
• powiedzieć, dlaczego wiadomość jest postrzegane (wyjątek powinny zostać wyrzucone i nie jest)

Na przykład

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

lub

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

Który z nich jest ogólnie preferowany/akceptowany?

Answer 1

Biorąc pod uwagę, że jest to kod testowy i nie powinien być wprowadzany do ostatecznej kompilacji, powiedziałbym, że im więcej gadek, tym lepiej. Jako taki, chciałbym iść z pierwszym - jest o wiele jaśniejsze, co jest główną przyczyną problemu, co ułatwia korygowanie.

Unikałbym drugiej w każdych okolicznościach, ponieważ nie jest to zbyt pomocne dla testera, a jeśli w jakiś sposób robi to w ostatecznej wersji, jest jeszcze bardziej zagadkowe niż pierwsze dla użytkownika końcowego - po prostu nie ma pomoc dla testerów lub użytkowników.

Inną opcją, którą bym rozważał, zamiast wskazywać, że wystąpił wyjątek, podano szczegóły rzeczywistego wyjątku - dlatego wynaleziono ślady stosu. Dałoby to więcej szczegółów niż każda z wymienionych metod.

Answer 2

Jeśli nie było były konwencji o tym będę zignorować. Powinieneś powiedzieć cokolwiek, co najlepiej komunikuje się z kimś, widząc tę ​​wiadomość, o charakterze problemu w taki sposób, aby można go było rozwiązać tak łatwo, jak to tylko możliwe. Zbyt często stosowanie się do konwencji kończy się niepowodzeniem.

Answer 3

Po pierwsze, jeśli oczekujesz API przetestować rzucić wyjątek, zamiast robić try-catch z fail() ...

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

... należy zrobić to: -

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

To powiedziawszy, rzadko używam fail(). Jeśli trzeba wykonać pewną walidację oraz warunek nie powiedzie się, że najprawdopodobniej twierdzeń obsłudze niż przy użyciu fail() ... na przykład: -

... zamiast ...

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

... to zrobić: -

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

Jednakże, jeśli naprawdę trzeba użyć fail() być rozwlekły i wyjaśnić, dlaczego nie zamiast „nie powinien dotrzeć tutaj” lub „nie powinny tu”, ponieważ to nie pomoże ludzi, którzy przeczytaj testcases.

To są po prostu proste przykłady ... ale myślę, że mam swoje punkty. :)