Jest sens unit testować strategie?

0

Mam projekt w którym jest około 25-30 case'ów rozwiązania sytuacji kryzysowej. Zrobiłem sobie na każdy z tych case'ów po jednym Strategy, i jedyna odpowiedzialność tych strategii to delegowanie do jakiejś metody innej klasy.

Jest sens couple'ingować testy z kodem po to żeby przetestować czy strategie dobrze delegują?

0

A te "inne klasy" masz przetestowane?

0

Czy jeśli ta część nie będzie działać to system się wywali? Tak? No to chyba sobie odpowiedziałeś ;) Ale nie musisz tego koniecznie unit testować z mockowaniem strategii. Możesz mieć jakieś testy które odpalają dany case i sprawdzają wyniki dla wszystkich opcji.

0
somekind napisał(a):

A te "inne klasy" masz przetestowane?

Yup

Shalom napisał(a):

Czy jeśli ta część nie będzie działać to system się wywali? Tak? No to chyba sobie odpowiedziałeś ;)

Tylko że te testy będą idealną kopią 1:1 klasy którą testują.

Równie dobrze można by pisać return 14 i assertEquals(result, 14). Niby fajnie że przetestowane, ale po co?

2

No dlatego ja bym przygotował przypadki testowe i wysyłał je do wykonania całej strategii. Jeśli wynik zwróci dobry, to znaczy, że oddelegowała do odpowiedniej klasy.

0
somekind napisał(a):

No dlatego ja bym przygotował przypadki testowe i wysyłał je do wykonania całej strategii. Jeśli wynik zwróci dobry, to znaczy, że oddelegowała do odpowiedniej klasy.

No przecież jasne że end-to-end testy pokrywają te strategie. Pytanie brzmi: Jest sens unit testować strategie?

0

Ale jakie end to end? Takie od GUI do bazy? Myślałem, że o testach jednostkowych mowa.

Mamy FooService i przypadki testowe: A i B. To, że FooService jest tak naprawdę strategią, i w przypadku A używa AInternalHelper, a w przypadku B używa BInternalHelper to jest szczegół implementacji.

0
somekind napisał(a):

Myślałem, że o testach jednostkowych mowa.

Tak i nie. Jest szereg testów pokrywających to zachowanie (integracyjne i funkcyjne). Nie ma pod to testów jednostkowych, i zastanawiam się czy one mają sens - jak mają to sobie klepnę, jak nie to.

Mam problem bo z jednej strony nie zaszkodzą, ale z drugiej strony czuję że nie mają żądnego sensu bo strategie nie mają żadnej logiki - one tylko wybierają ścieżkę, więc po co niby ktoś miałby to testować.

4

Powinno to działać w drugą stronę: jeśli masz takie AInternalHelper i BInternalHelper składające się na fasadę/strategię FooService, to właśnie tylko FooService powinieneś testować z wszystkimi przepadkami brzegowymi, a nie jej wewnętrzne składowe (które mogą ulec zmianie w każdej chwili, bo są tylko szczegółem związanym z tą konkretną implementacją).

Dzięki temu sprawdzasz działanie podmodułu jako całości (zarówno to, czy dobrze rozpoznaje przypadki i odpala odpowiedni handler, jak i czy zwraca odpowiednie rezultaty).

Zatem IMO warto przepisać te Twoje obecne testy tak, aby nie odwoływały się do klas wewnętrznych, tylko testowały ogólnie FooService.

0
Patryk27 napisał(a):

Powinno to działać w drugą stronę: jeśli masz takie AInternalHelper i BInternalHelper składające się na fasadę/strategię FooService, to właśnie tylko FooService powinieneś testować z wszystkimi przepadkami brzegowymi, a nie jej wewnętrzne składowe (które mogą ulec zmianie w każdej chwili, bo są tylko szczegółem związanym z tą konkretną implementacją).

Tak właśnie testują to testy integracyjne i funkcyjne.

Zatem IMO warto przepisać te Twoje obecne testy tak, aby nie odwoływały się do klas wewnętrznych, tylko testowały ogólnie FooService.

Ale one się nie odwołują do wewnętrznej implementacji (nawet nie wiedzą że są jakieś strategie pod spodem).



Sugeruję @Patryk27 i @somekind przeczytać jeszcze raz tytuł tego wątku i pytanie w temacie

TomRiddle napisał(a):

Jest sens couple'ingować testy z kodem po to żeby przetestować czy strategie dobrze delegują?

Bo od początku pytam czy jest sens pokrywać unit testami strategie które jedyne co robią to delegują zachowanie?

0

Problem chyba polega na tym, że Ty testy jednostkowe jednostki (na którą składa się strategia + jakieś tam wewnętrzne serwisy realizujące faktyczną logikę) nazywasz integracyjnymi i funkcyjnymi.

Wracając do pytania:

czy jest sens pokrywać unit testami strategie które jedyne co robią to delegują zachowanie?

Nie, bo to nie będzie test jednostkowy tylko test klasy.

3

Samej strategii nie ma sensu pokrywać - pokrycie strategii powinno wynikać z testów jednostkowych / integracyjnych / whatever.

Jeśli testujesz FooService (niezależnie w jaki sposób) i dla każdego przypadku zwraca poprawne dane, to znaczy, że już masz przy okazji pokrytą tę strategię. O ile właśnie nie robisz sondy analnej w szczegóły implementacyjne (klasy pomocnicze), tylko sprawdzasz ten FooService.

0
Patryk27 napisał(a):

Samej strategii nie ma sensu pokrywać - pokrycie strategii powinno wynikać z testów jednostkowych / integracyjnych / whatever.

Jeśli testujesz FooService (niezależnie w jaki sposób) i dla każdego przypadku zwraca poprawne dane, to znaczy, że już masz przy okazji pokrytą tę strategię. O ile właśnie nie robisz sondy analnej w szczegóły implementacyjne (klasy pomocnicze), tylko sprawdzasz ten FooService.

Przecież powtarzam już 4ty raz że mam takie testy, i zdaję sobie sprawę że one pokrywają tą logikę "w dół".

0

No okej, okej - zadałeś pytanie Czy jest sens testować samą strategię?, na co udzieliłem wyżej wprost odpowiedź: nie ma sensu z drobnym wytłumaczeniem dlaczego :-P

0
Patryk27 napisał(a):

No okej, okej - zadałeś pytanie Czy jest sens testować samą strategię?, na co udzieliłem wyżej wprost odpowiedź: nie ma sensu z drobnym wytłumaczeniem dlaczego :-P

screenshot-20190109131320.png
to napisałeś tylko "Samej strategii nie ma sensu pokrywać", A potem - z drobnym wytłumaczeniem dlaczego - opisałeś czemu wartałoby zrobić tak żeby to pokrycie wynikało z testów klasy wyżej (dodam nieskromnie, że zdawałem sobie z tego sprawę, wiec od dawna takie testy są :D).

Rozumiem że wy takiej stretegii byście nie testowali, ponieważ:

  • argumenty dla "Nie robić testów pod samą strategię":
  • Po co, skoro pokryte są przez klasę wyżej
  • argumenty dla "Robić testy pod samą strategię":
  • Brak

Zauważcie tylko, że jestem dokładnie w tym samym punkcie, w którym byłem zadają pytanie. I nadal się nie dowiedziałem od forumowiczów niczego, czego nie wiedziałbym zadają pytanie :/

Temat chyba do zamknięcia.

0

Zauważcie tylko, że jestem dokładnie w tym samym punkcie, w którym byłem zadają pytanie

Twój pierwszy post nie implikuje w żaden sposób, że jesteś świadom tego, co napisałeś dopiero teraz:

dodam nieskromnie, że zdawałem sobie z tego sprawę, wiec od dawna takie testy są

Ya' know - jeśli kilka osób zaczyna odpisywać na - według Ciebie - niewłaściwy temat, to może jednak problem nie tkwi w tych kilku innych osobach :-P

Spróbuj zadać to pytanie raz jeszcze, może opowiedz jakiej odpowiedzi oczekujesz - aktualnie rozumiem tyle z tego, że wiem, że nie warto testować strategii. a powiecie mi może dlaczego nie warto testować strategii?.

0
Patryk27 napisał(a):

Spróbuj zadać to pytanie raz jeszcze, może opowiedz jakiej odpowiedzi oczekujesz - aktualnie rozumiem tyle z tego, że wiem, że nie warto testować strategii. a powiecie mi może dlaczego nie warto testować strategii?.

Prędzej nie wiem, czy nie warto testować strategii. a powiecie mi może czy warto czy nie warto testować strategii?. Ale tak.

Zaznaczam że jednostkowo (czy klasowo, jak ktoś to ujął) - w teście który wie tylko o tej strategii.

0

Pytanie, jak one delegują te klasy. Jeśli w nie ma tam ani ifów ani pętli, to nie ma co testować.

Testy nigdy się nie "couple'inguje z kodem" sprawdź wzorce czerwonego paska.

2
Bambaryła napisał(a):

Testy nigdy się nie "couple'inguje z kodem" sprawdź wzorce czerwonego paska.

Lepiej Ty sprawdź London School of Testing, to nie będziesz takich bzdur pisał.

6

Właśnie - London School of Testing. Prawdpopodobnie problem polega na tym, że chcesz na siłe tworzyć tzw. testy bezsensowne - czyli inaczej jednostkawe, które testują tylko kod z jednej klasy i nie mogą W ŻADNYM RAZIE z innych. Wtedy oczywiście mockujemy wszytko Strategie, HashMapy i Stringa (bo jak Oracle coś zmieni w klasie String to nasz test się wywali, a to znaczy, że nie jest jednostkowy).
I po jakimś czasie odkrywamy jednak, że takie testy są bez sensu. Faktycznie, są.

Można jednak nie mockować.

0
somekind napisał(a):
Bambaryła napisał(a):

Testy nigdy się nie "couple'inguje z kodem" sprawdź wzorce czerwonego paska.

Lepiej Ty sprawdź London School of Testing, to nie będziesz takich bzdur pisał.

Przeczytam a miałem na myśli fabrykę lub metodę fabrykującą.

0

Nie mogę znaleźć tej książki. Na pewno dobrze napisałeś tytuł?
Poza tym, co widzisz złego w tym, co napisałem?

0

Jakiej książki? London School of Testing to nazwa patologicznego zjawiska, jednej z wielu chorób toczących branżę, a nie tytuł książki.

0

Nie wiem co teraz jest na topie w konferencjach. W sumie mnie to nie obchodzi.

Nie wiem co widzisz złego w zmniejszaniu couplingu fabryką.

@jarekr000000
Jak ktoś sobie wkręca, że trzeba "mockować" stringa, to znaczy, że nie ma pojęcia co to jest jednostka ani mock. Samo nadużywanie zdeformowanego znaczenia słowa "mock", świadczy o "słabiej wiedzy".

0
Bambaryła napisał(a):

Nie wiem co widzisz złego w zmniejszaniu couplingu fabryką.

Nigdzie czegoś takiego nie napisałem.

Ja się odniosłem do tego, że napisałeś, że testów się nie wiąże z kodem, tymczasem jest to bzdura, bo jakieś 80% programistów tak robi.

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