Jest sens unit testować strategie?

Odpowiedz Nowy wątek
2019-01-07 22:54
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ą?


Pozostało 580 znaków

2019-01-08 00:37
0

A te "inne klasy" masz przetestowane?


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2019-01-08 09:19
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.


Masz problem? Pisz na forum, nie do mnie. Nie masz problemów? Kup komputer...

Pozostało 580 znaków

2019-01-08 17:27
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?


edytowany 1x, ostatnio: TomRiddle, 2019-01-08 17:29

Pozostało 580 znaków

2019-01-08 17:36
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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2019-01-09 10:40
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?


Pozostało 580 znaków

2019-01-09 11:53
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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2019-01-09 12:30
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ć.


edytowany 2x, ostatnio: TomRiddle, 2019-01-09 12:30

Pozostało 580 znaków

2019-01-09 12:42
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.


edytowany 2x, ostatnio: Patryk27, 2019-01-09 12:43
No i ja o tym właśnie piszę od początku. - somekind 2019-01-09 12:43
No przecież jasne że dobrze przetestować klasę zewnętrzną, tak żeby testy nie wiedziały o implementacji. Nie na tym polegało pytanie. - TomRiddle 2019-01-09 12:55

Pozostało 580 znaków

2019-01-09 12:54
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?


Pozostało 580 znaków

2019-01-09 13:00
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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
To mieliśmy inne nazewnictwo. Ja testem jednostkowym nazywałem test który wie tylko o jednej klasie, i nic nie wie o jej zależnościach. - TomRiddle 2019-01-09 13:02

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