Temat: Czy jeden test powinien testować jedną rzecz?

W teorii to zawsze wszysto ładnie wygląda i działa. A jakie jest Wasze zdanie na ten temat? Czy jeden test powinien testować jedną rzecz/przypadek?
Czy widzicie jakieś plusy/minusy takiego podejścia?

I co najważeniejsze - czy sami to praktykujecie?

Dla mnie jedynym zauważalnym minusem może być ilość kodu/metod, ale to jest minus, który do mnie nie przemawia :) Natomiast o plusach takiego podejścia z mojego punktu widzenia napisałem tutaj:
http://sebastian-malaca.blogspot.com/2013/08/test-zeby...

Temat: Czy jeden test powinien testować jedną rzecz?

Wg mnie, może testować więcej niż jeden przypadek - tak długo jak są z jednego zbioru.

Temat: Czy jeden test powinien testować jedną rzecz?

Michał W.:
Wg mnie, może testować więcej niż jeden przypadek - tak długo jak są z jednego zbioru.

Nie sądzisz, że wprowadziłoby to "odrobinę" zamieszania i mogłoby negatywnie wpłynąć na czytelność testów?
Poza tym, jakbyś taki test nazwał? Wydaje mi się, że z odpowiednimi nazwami metod testowych ich zbiór z powodzeniem zastępuje dokumentacje, daje nam doskonały obraz tego, co można i jakie są ograniczenia funkcjonalności.
Jeżeli przypadki są powiązane i zależne, to zawsze można dodać odpowiednią adnotację do testu, co również dostarcza informacji przyszłym jego czytelnikom, bo od razu (bez analizowania kodu) wiedzą jakie założenia musi spełnić aby kod zaczął działać tak, jak chcemy.

Temat: Czy jeden test powinien testować jedną rzecz?

Sebastian M.:
Nie sądzisz, że wprowadziłoby to "odrobinę" zamieszania i mogłoby negatywnie wpłynąć na czytelność testów?

I tak i nie.
Jeżeli test sprawdza zachowanie dla zbioru danych, nawet jednoelementowego.
Dla przykładu, przypadki dla sqrt():
- liczby całkowitych, dodatnich
- liczby ułamków, dodatnich
- liczby całkowitych, ujemnych
- liczby ułamków, ujemnych
- przypadki specjalne 0 i 1
Ja bym z tego zrobił trzy testy - dla liczb dodatnich, ujemnych i przypadki specjalne :)

Sebastian M.:
Poza tym, jakbyś taki test nazwał? Wydaje mi się, że z odpowiednimi nazwami metod testowych ich zbiór z powodzeniem zastępuje dokumentacje, daje nam doskonały obraz tego, co można i jakie są ograniczenia funkcjonalności.

Testy nazywał bym tak, jak testowana operacja: testNegativeFloats, testPositiveFloats, testZero i testOne.
Inny przykład - wg Ciebie, należało by osobno testować getter i setter. Działanie gettera sprawdzam setterem, zaś settera - getterem.
Wg mnie to jest jeden testAccessor, rozbijanie tego nie ma najmniejszego sensu.
Przecież nie będziesz sprawdzać działania getterów/setterów włamując się do obiektów? :)

Temat: Czy jeden test powinien testować jedną rzecz?

To chyba kwestia upodobań... osobiście patrzę na wielkość testów, jeżeli metoda testująca robi się zbyt duża to ja rozbijam (yup, refactoring testów to też refactoring :D) i ewentualnie używam phpUnitowego @depends aby przekazać testowany obiekt dalej.Ten post został edytowany przez Autora dnia 18.08.13 o godzinie 21:50

Temat: Czy jeden test powinien testować jedną rzecz?

Michał W.:

Sebastian M.:
Nie sądzisz, że wprowadziłoby to "odrobinę" zamieszania i mogłoby negatywnie wpłynąć na czytelność testów?

I tak i nie.
Jeżeli test sprawdza zachowanie dla zbioru danych, nawet jednoelementowego.
Dla przykładu, przypadki dla sqrt(): [...]
Ja bym z tego zrobił trzy testy - dla liczb dodatnich, ujemnych i przypadki specjalne :)
[...]
Testy nazywał bym tak, jak testowana operacja: testNegativeFloats, testPositiveFloats, testZero i testOne.

To się źle zrozumieliśmy. Dla mnie to wygląda podobnie. Źle zinterpretowałem Twoją wypowiedź. Ja pisałem o przypadku w sensie "przypadek użycia", a Tobie chodziło o inne dane. Stąd wynikło nieporozumienie :)

Inny przykład - wg Ciebie, należało by osobno testować getter i setter. Działanie gettera sprawdzam setterem, zaś settera - getterem.
Wg mnie to jest jeden testAccessor, rozbijanie tego nie ma najmniejszego sensu.

Nie popadajmy w skrajności:)
Po pierwsze, prostych akcesorów staram się unikać (i o dziwo wychodzi to wszystkim na zdrowie pomimo początkowych oporów :). Po drugie, jeżeli już je stosuje, to raczej testuję je pośrednio, nie piszę oddzielnych metod testowych.

Przecież nie będziesz sprawdzać działania getterów/setterów włamując się do obiektów? :)

Jak mam taką potrzebę (bo "inaczej się nie da") to znaczy, że pora na refaktoring :)

Temat: Czy jeden test powinien testować jedną rzecz?

Alan Gabriel B.:
To chyba kwestia upodobań...

Zgadzam się, że wiele rzeczy to kwestia osobistych preferencji, ale w wielu przypadkach warto stosować się do praktyk i wzorców oraz korzystać z doświadczenia innych programistów, ponieważ niekiedy nasze "upodobania" po pewnym czasie mogą okazać się błędami, na których się uczymy :)

osobiście patrzę na wielkość testów, jeżeli metoda testująca robi się zbyt duża to ja rozbijam

Osobiście boję się takiego podejścia tzn. takich nieweryfikowalnych skal, bo co oznacza "zbyt duża"? Masz jakąś z góry założoną ilość linii kodu? Co ze stopniem skomplikowania testu? Itp., itd.

Dlatego uważam, że lepiej skupiać się na testowaniu jednej rzeczy.
Mam podejście, że jeżeli nie potrafię napisać nazwy metody testowej, która w jasny i prosty sposób informuje o tym, co jest testowane, to włącza mi się czerwona lampka sygnalizująca, że metoda może testuje zbyt wiele.
To samo, jeżeli w nazwie pojawia się łącznik.

Do tej pory sprawdza się nieźle :)

ewentualnie używam phpUnitowego @depends aby przekazać testowany obiekt dalej.

I to jest całkiem rozsądne w wielu przypadkach.