Skip to main content

Generyczne testy z adnotacją Parameters w JUnit 4

Wydawałoby się, że JUnit jest na tyle prostą biblioteką, iż nic nie jest w stanie nas w niej zaskoczyć. A jednak, odkryłem niedawno ciekawą adnotację @Parameters pozwalającą na generowanie testów z dostarczonych danych. Przykład wiele rozjaśni:

@RunWith(Parameterized.class) 
public class ParamsTest {
private int a;
private int b;
private int expected;

@Parameters
public static Collection data() {
return Arrays.asList(new Object[][] { { 1, 1, 2 }, { 1, 2, 3 }, { 4, 6, 9 }, { -2, 2, 0 } });
}

public ParamsTest(int a, int b, int expected) {
this.a = a;
this.b = b;
this.expected = expected;
}

@Test
public void sum() {
assertEquals(expected, a + b);
}
}


Należy zwrócić uwagę na dwie rzeczy:
brak konstruktora bezargumentowego; normalnie JUnit nie byłby w stanie uruchomić jakiegokolwiek testu z tekiej klasy
metoda data() zwraca kolekcję tablic.

JUnit automatycznie dla każdego elementu kolekcji zwróconego przez metodę data() tworzy instancję klasy ParamsTest. A co wstrzykuje do argumentów konstruktora? Oczywiście wartości z tablicy bieżącego elementu kolekcji. Przykładowo pierwszy test:

new ParamsTest(1, 1, 2)


Dla każdej instacji klasy ParamsTest zostaną oczywiście wywołane wszystkie testy, zatem nie jeden sum, a cztery: sum[0], sum[1], sum[2], sum[3]. W podanym przykładzie błędem zakończy się test o nazwie sum[2]. Potrafisz powiedzieć czemu?

Comments

  1. No jasne ;-)

    Źle napisałeś test, bo 4+6 to nie jest 9 :P.

    I tu tkwi problem całego TDD. że źle napisane testy nie pomogą w polepszeniu kodu :P

    A swoją ścieżką, to przedstawione adnotacje zmniejszają ilość niezbędnego kodu, do przetestowania wielu wariantów. ich minus to nie-nazwanie.

    do tych tablic argumentów nie przypisane są nazwy jak np. 'overflow test' 'minus test', które by opisywały, jaką sytuację testujemy.

    Racjonalny Developer

    ReplyDelete

Post a Comment