Wpis z mikrobloga

A co by mogło w tej linijce pójść nie tak, że potrzebny ci test?


@Kresse: testy nie służą do sprawdzania, czy coś idzie nie tak, tylko do sprawdzania, czy wszystko działa tak, jak chcemy. Wystarczy, że ktoś zamiast save() wywoła np. saveAndFlush, i już nasze testy mogłyby to wykryć.
@kamil159 można przetestować czy dane zapisały się poprawnie.
Baza mogłaby mieć np. jakieś pole ustawione na default, a Ty w parametrze przesyłasz null i oczekujesz, że po zapisie też będzie null.
Ale tak jak napisał @Leihto to jest już test integracji
@Leihto: @kornfan: @kamil159: tak jak koledzy wyżej napisali, to będzie test integracyjny. Jednostkowy by był, jakbyś w tym Save coś testował.
Ogólnie pod tym Save powinieneś mieć jakieś testy jednostkowe. A czy do wspomnianej metody pisać testy to sam musisz się zastanowić pod kątem integracji.
@fegwegw: Chodzilo mi raczej o to, jakie bledy moglby w tej linijce popelnic programista. Ich liczba jest znikoma i dlatego (jednostkowe) testowanie tego nie ma wiekszego sensu.
Chodzilo mi raczej o to, jakie bledy moglby w tej linijce popelnic programista.


@Kresse: może np. całkowicie usunąć tę linie. Wtedy test się wywala, bo kontrakt zawarty przy pisaniu tego fragmentu systemu przestał obowiązywać - bez testu jesteś w dupie, możesz godzinami debugować i nic nie znaleźć.
@fegwegw: Moze wszystko, ale jesli cos takiego robi, to raczej powinien zmienic branze. Oczywiscie mozna testowac tego typu metody, jak i wygenerowane przez IDE gettery/settery i byc w 200% bezpiecznym, ale imho koszty takich testow sa niewspolmierne do korzysci. Wiekszosc takich bledow i tak wychodzi przy porzadnym tescie integracyjnym.