TDD problem

0

Cześć,
Możecie z własnego doświadczenia podzielić się tym jak radziliście sobie na początku drogi z TDD ?

Przerobiłem 2 książki z tego zakresu: Kenta Becka oraz T. Kaczanowskiego.
Jednak w tym książkach przykłady są trywialne i bardzo proste: pisanie testów kolekcji czy jakichś niezłożonych obiektów.
A schody zaczęły się jak w TDD chciałem pisać złożoną aplikację w Springu gdzie obiekty wchodzą w interakcje z innymi itd.
Jak testować metody prywatne? Walić wszędzie refleksję czy PowerMocki? Te powermocks do mnie w ogóle jak na razie nie przemawiają.
No i jak metoda jest void i to też jest mi ciężko do tego podejść.

Chciałbym się nauczyć pisać kod zgodnie z zasadą Martina "Nie wolno napisać ani linijki kodu bez testów", ale po prostu nie umiem tego i chciałem się zapytać o jakieś skuteczne metody.

PS: Czy znacie jakieś wspaniałe pozycje / artykuły o dobrych praktykach i zasadach testowania?
Ogólnie to rwę włosy z głowy, bo ciągle łamię zasady z "Czystego kodu".

Pozdrawiam.

2
NeutrinoSpinZero napisał(a):

w TDD chciałem pisać złożoną aplikację w Springu

Tu leży problem. Jak nie używam Springa to i testy mam proste.
Btw. w Springu też się da, ale to po prostu chore.

NIe używaj powermocka i nie testuj metod prywatnych.

I tu zasada najważniejsza: NIGDY nie testuj ŻADNYCH metod.

Testuj co program, obiekt, moduł ma robić - pewnie w tym celu będziesz potrzebował wywołać jakąś metodę i pewnie publiczną, ale to jakby efekt dodatkowy.
Metody void to świnie - unikaj jak ognia.

0

@jarekr000000: dzięki za odpowiedź. W 'Czystym kodzie' jest zasada, że każda metoda musi być pokryta testami i wprowadza mnie to w koszmar.
Wkrótce będę pokazywał mój kod w CV i nie chciałbym, żeby jakiś fragment był 'goły'.

0

Z tego co piszesz to wynika, że nie umiesz pisać testów do aplikacji Springowej nawet nie w TDD. Jak się nauczysz testować Springa to z TDD nie będziesz mieć problemu. Co do testowania metod prywatnych to ich się bezpośrednio nie testuje, skoro są prywatne to woła je jakaś publiczna metoda, której działanie należy przetestować.

0

To, że ma być pokryta testami nie znaczy, że musi mieć swój własny test. Równie dobrze może być jedną z metod w teście (np. w teście wywołujesz metodę publiczną, która woła prywatną). Tak jak @jarekr000000 mówi - testuj zachowania, wtedy ta zasada jeśli już jej się chcesz trzymać będzie prostsza do spełnienia i intuicyjna.

2

@NeutrinoSpinZero: pokrycie testami nie jest tożsamym pojęciem z napisaniem testu. Jeżeli masz przepływ w postaci:


public Ok mojaMetoda(){
     metodaA();
     metodaB();
     metodaC();   
     return ok;
}

Coś metodaA(){}
Coś metodaB(){}
Coś metodaC(){}

to testowanie mojaMetoda powoduje, że test pokrywa też metodaA/B/C. O tym właśnie pisze @jarekr000000, gdy pisze o testowaniu programu. Dokładnie chodzi o testowanie pojedynczej ścieżki przejścia dla danej funkcjonalności/przypadku użycia.

Co do Springa, to problem leży gdzieś indziej. Zazwyczaj tworząc bean springowy używasz wstrzykiwania zależności przez pola (property based), To powoduje, że pomiędzy utworzeniem obiektu, a osiągnięciem przez niego prawidłowego stanu jest moment, gdy jest on nieprawidłowy. W czasie działania aplikacji Spring ogarnia ten moment i nie udostępnia ci obiektu, ale w testach to musisz sam obsłużyć. Zazwyczaj stosowane jest rozwiązanie naiwne czyli użycie Spring Test i stawianie kontekstu, w którym masz podpięte mocki zamiast "prawdziwych" zależności. To utrudnia testowanie i powoduje, że testy jednostkowe długo się wykonują.
Prawidłowym podejściem jest wykorzystanie wstrzykiwania przez konstruktor. W tym momencie możesz w teście samodzielnie podstawić sobie jakiegoś mocka i łatwiej jest napisać test.

0

Dziękuję za pomoc. @Koziołek faktycznie teraz mi pomogłeś, bo myślałem, że muszę najpierw przetestować metody oddzielnie, a potem ich przepływ.

PS: Mam pytanie co do getterów. Chcę sprawdzać np. czy pola nie są null i czy warto dawać gettery tylko na potrzeby testów? Czy to jest poprawne?

1

@NeutrinoSpinZero: nie warto. Lepiej napisz test, który odzwierciedla przypadek użycia takiego pola. Jeżeli nie umiesz go wymyślić, to usuń pole i tak go nie używasz.

4

Nie testuj getterów. A najlepiej nie rób getterów.

1 użytkowników online, w tym zalogowanych: 0, gości: 1