Jaki obrać styl tworzenia testów jednostkowych

Cześć,

Mój problem polega na tym, że znam frameworki do testów jednostkowych, ale nie mam wypracowanego stylu tworzenia testów, więc pomyślałem, że pomożecie mi taki wypracować na bazie własnych doświadczeń.

Korzystam z frameworków spock lub zestawu JUnit4 i mockito 1.8.4. Osobiście preferuję spocka, ale nie wiem czy ktoś tu korzysta z niego, bo chyba nie jest on zbyt popularny, więc przykłady niech będą w JUnit4.

1. Klasa testu powinna obejmować jedną metodę czy jedną klasę.

Czyli tworzycie test dla pojedynczej klasy i w środku testu (tzn. klasie) znajdują się różne metody oznaczone adnotacją @Test, które testują konkretne metody danej klasy lub można utworzyć klasę testu aby testowała pojedynczą metodę i w tej klasie znajdowały się metody testujące różne scenariusze dla danej metody np. czy wyrzuci wyjątek itp. Problem z pierwszym sposobem jest taki, że zdarzają się sytuacje kiedy w pojedynczej klasie mam mnóstwo metod testowych, przez co ta klasa osiąga mnóstwo linijek kodu. Drugie podejście znów powoduje ogromną eksplozję klas.

2. Jak organizujecie swoje testy w pakietach?
3. Nazewnictwo testów:

Preferujecie nazwy dla swoich testów bardziej behawioralne w stylu "it should create object" tego typu stosuję w spocku, ale on jest frameworkiem BDD, więc to zrozumiałe. Drugi sposób standardowy, który daje znać jaką metodę testujemy np. "objectCreatorTest".

pozdrawiam

Zacznij od http://4programmers.net/Forum/Inzynieria_oprogramowania/245424-unit_test_-_kiedy_klasa_jest_zalezna_od_innej :D

Podlinkowany przez @Shalom wątek ani trochę nie odpowiada na pytania autora tego wątku, a i tak dostał 2 głosy. Widać, ktoś się zakochał. :P

pablo123 napisał(a):

Problem z pierwszym sposobem jest taki, że zdarzają się sytuacje kiedy w pojedynczej klasie mam mnóstwo metod testowych, przez co ta klasa osiąga mnóstwo linijek kodu. Drugie podejście znów powoduje ogromną eksplozję klas.

Jeśli mam dużo przypadków testowych, to dzielę klasę testów tak, aby testy dotyczące jednej metody/scenariusza znajdowały się w oddzielnych klasach.
Drugą motywacją do podziału jest taka sama "sekcja" arrange w wielu metodach testujących. W tym przypadku warto je wszystkie przenieść do nowej klasy, a kod przygotowujący testy przenieść do metody setupu.

Dużo klas nie boli tak bardzo jak dziesiątki metod w jednej. Ja bez względu na rodzaj klasy staram się nie przekraczać 300 linii kodu w niej.

2. Jak organizujecie swoje testy w pakietach?

Per typ testu i nazwę funkcji (przypadku użycia), którego dotyczą.

Preferujecie nazwy dla swoich testów bardziej behawioralne w stylu "it should create object" tego typu stosuję w spocku, ale on jest frameworkiem BDD, więc to zrozumiałe. Drugi sposób standardowy, który daje znać jaką metodę testujemy np. "objectCreatorTest".

Ja preferuję rozwiązanie porządne:

NazwaMetodyTestowanej_OpisPrzypadkuTestowego(np.ParametryWejściowe)_OczekiwanyRezultat

Z pierwszej części nazwy możemy zrezygnować, jeśli nazwa metody testowanej jest zawarta w nazwie klasy testującej.

ad1. Testuje cala klase. Jezeli problemem jest pojawienia sie mnostwa metod do testowania to moze sygnalizowac to, ze klasa testowana jest zbyt skomplikowana i trzeba ja rozbic na mniejsze. Ewentualnie testy mozna napisac jakos sprytnie np. sparametryzowac je.

ad2. Identyczna struktura pakietow jak klas testowanych. Wydaje mi sie to czytelne oraz otwiera to pewne dodatkowe techniki testowania np. nadanie metodzie zasiegu pakietowego zamiast prywatnego w celu jej przetestowania wprost. Chociaz generalnie metody prywatne powinny byc pokryte przez testy metod publicznych, ale zawsze ta organizacja pakietow otwiera w razie czego taka mozliwosc.

ad3. Preferuje wzorzec: shouldDoSthWhen. Dodatkowo warto w nazwie klasy okreslic czy mamy do czynienia z czystym junitem, czy takim ktory jest testem integracyjnym poprzez dodanie TestIt albo IntegrationTest do nazwy.