TDD problem

Odpowiedz Nowy wątek
2018-05-08 12:22
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.

Pozostało 580 znaków

2018-05-08 12:24
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.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 5x, ostatnio: jarekr000000, 2018-05-08 12:27

Pozostało 580 znaków

2018-05-08 12:57
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'.

Pozostało 580 znaków

2018-05-08 13:03
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ć.

Pozostało 580 znaków

2018-05-08 13:08
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.


Pozostało 580 znaków

2018-05-08 13:15
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.

Pozostało 580 znaków

2018-05-08 13:46
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?

Pozostało 580 znaków

2018-05-08 14:14
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.

Pozostało 580 znaków

2018-05-08 14:15

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


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
Niby tak, ale to się często gryzie z różnymi bibliotekami Javowymi które z jakiegoś powodu zakładają ich istnienie. - Fedaykin 2018-05-08 14:40
Coraz mniej się gryzie. W zasadzie nawet dla jpa nie muszę ich robić. - jarekr000000 2018-05-08 14:56
@Fedaykin: podbij wersję biblioteki :) - Koziołek 2018-05-08 15:10
@jarekr000000: czemu odradzasz gettery? - discoStar 2018-05-21 11:54
@Koziołek: super seria, dziękuję :) - discoStar 2018-05-22 11:09

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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