Testy jednostkowe klasy dziedziczącej po klasie bazowej

Odpowiedz Nowy wątek
2019-04-29 10:56
0

Hej, takie pytanie mi się nasunęło. Mam jakąś ABSTRAKCYJNĄ klasę bazową Item. Po niej dziedziczą inne klasy: A, B, C, D, E itd.

I teraz chciałbym zrobić testy jednostkowe klasy A. Czy powinienem zawrzeć tutaj również testy dla klasy bazowej i to samo zrobić w reszcie klas, czy jakoś inaczej. Jak takie rzeczy testujecie u siebie?

Pozostało 580 znaków

2019-04-29 10:59
1
  1. W jaki sposób chcesz napisać testy do klasy abstrakcyjnej bez zabawy w sondę analną?
  2. Przerobiłbym hierarchię klas na kompozycję i napisał testy zgodne z tym, jakie każda z klas ma zachowanie.

edytowany 1x, ostatnio: Patryk27, 2019-04-29 11:00

Pozostało 580 znaków

2019-04-29 11:14
0

Ad. 1. Nie wiem. Dlatego pytam.
Ad. 2. Nie chcę tego robić, bo mam już dziedziczenie ogarnięte. Ja wiem, że są fanatycy, którzy krzyczą, że kompozycja uber alles, ale bez przesady :)

Więc tak to ogarnąć poprawnie bez zmiany dziedziczenia na kompozycję?

Pozostało 580 znaków

2019-04-29 11:28
1
Juhas napisał(a):

Ad. 1. Nie wiem. Dlatego pytam.
Ad. 2. Nie chcę tego robić, bo mam już dziedziczenie ogarnięte. Ja wiem, że są fanatycy, którzy krzyczą, że kompozycja uber alles, ale bez przesady :)

Więc tak to ogarnąć poprawnie bez zmiany dziedziczenia na kompozycję?

Ad. 2. Czyli jedynym argumentem za tym żeby zostawić bad design (dziedziczenie), jest to że już to zrobiłeś? Outstanding move

Jedynym sposobem wtedy jest w testach zrobić kolejną implementację klasy abstrakcyjnej, która nie będzie miała żadnej dodatkowej logiki. Będzie służyła tylko do tego żeby w testach zainstancjonować i przetestować. Jeśli natomiast ta Twoja klasa abstrakcyjna udostępnia logikę przez metody protected albo pola protected, no to takiego ograniczenia (które sam sobie stworzyłeś) bez sond analnych (jak pokazał @Patryk27) się nie obejdzie.

PS: Albo ewentualnie z klasy abstrakcyjnej wydzielić zachowanie do innej klasy (kompozycja) i tą nową wydzieloną klasę przetestować. Wtedy właściwie Twoja klasa abstrakcyjna mogłaby się stać interfejsem (chyba że ma pola i trzyma stan).


char mander; bool basaur;
Zaawansowana biblioteka T-Regx do wyrażeń regularnych w PHP
edytowany 1x, ostatnio: TomRiddle, 2019-04-29 11:29

Pozostało 580 znaków

2019-04-29 11:46
0

Dlaczego uważasz, że podstawowe założenie programowania obiektowego to bad design?

Pozostało 580 znaków

2019-04-29 12:07
0

W uproszczeniu:
Kiedy dziedziczysz A -> B -> C -> ...
W klasie B masz wspólne zachowanie klasy A.
W klasie C masz wspólne zachowanie z klasy A i klasy B.

Niekoniecznie, ale możliwe, że będziesz musiał napisać testy dla:
w A (testy dla A)
w B (testy dla A oraz testy dla B)
w C (testy dla A, testy dla B oraz testy dla C)
itd...

Kompozycją elminujesz powtarzające się testy. Wszystko zależy od konkretnego przypadku.
Jeśli zachowanie B zależy od zachowania A to wtedy musisz testować wszystko od początku, itd.
Jest to silne wiązanie którego warto unikać, może że są ku temu przesłanki.

Pozostało 580 znaków

2019-04-29 12:20
0

Ja wiem, że dziedziczenie może przeszkadzać w testach. Ale nadal nie uważam tego jako bad design. No, chyba że się tego nadużywa. Tak jak ze wszystkim.

Pozostało 580 znaków

2019-04-29 15:03
0
Juhas napisał(a):

Ja wiem, że dziedziczenie może przeszkadzać w testach. Ale nadal nie uważam tego jako bad design. No, chyba że się tego nadużywa. Tak jak ze wszystkim.

Wady dziedziczenia/Zalety kompozycji:

  • Mniejszy coupling klas
  • Można użyć interfejsów: co oznacza możliwość wielu implementacji; zmiany/ustalenia zachowanie w runtime'ie zamiast compile-time, etc.
  • Łatwiejsze testowanie
  • Łatwiejsze mockowanie
  • Łatwiej użyć ponownie już istniejącej logki
  • Łatwiej zmienić kompozycję na np. kontenery DI jak Spring
  • Jest pierdyliard wzorców projektowych, które wykorzystują kompozycję. Wzorców z dziedziczeniem nie znam żadnych
  • Zmiana interfejsu klasy bazowej nie oznacza zmiany interfejsu klasy dziedziczącej
  • Dziedziczyć możesz tylko z jednej klasy, z kompozycją możesz mieć tyle zależności ile chcesz

Zalety dziedziczenia/Wady kompozycji:

  • ?

Chyba już znasz powód.


char mander; bool basaur;
Zaawansowana biblioteka T-Regx do wyrażeń regularnych w PHP
edytowany 6x, ostatnio: TomRiddle, 2019-04-29 15:12

Pozostało 580 znaków

2019-04-29 15:07
1
Juhas napisał(a):

Hej, takie pytanie mi się nasunęło. Mam jakąś ABSTRAKCYJNĄ klasę bazową Item. Po niej dziedziczą inne klasy: A, B, C, D, E itd.

I teraz chciałbym zrobić testy jednostkowe klasy A. Czy powinienem zawrzeć tutaj również testy dla klasy bazowej i to samo zrobić w reszcie klas, czy jakoś inaczej. Jak takie rzeczy testujecie u siebie?

A co to są testy klasy bazowej? Powinieneś testować API klas A, B, C i tak dalej, to czy one z czegoś dziedziczą nie ma żadnego znaczenia.


"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-04-29 15:08
0
somekind napisał(a):
Juhas napisał(a):

Hej, takie pytanie mi się nasunęło. Mam jakąś ABSTRAKCYJNĄ klasę bazową Item. Po niej dziedziczą inne klasy: A, B, C, D, E itd.

I teraz chciałbym zrobić testy jednostkowe klasy A. Czy powinienem zawrzeć tutaj również testy dla klasy bazowej i to samo zrobić w reszcie klas, czy jakoś inaczej. Jak takie rzeczy testujecie u siebie?

A co to są testy klasy bazowej? Powinieneś testować API klas A, B, C i tak dalej, to czy one z czegoś dziedziczą nie ma żadnego znaczenia.

Niby tak, ale wtedy albo miałby zduplikowane testy, albo musiałby mieć jeden test który testuje np A+Bazową i pozostałe B i C.


char mander; bool basaur;
Zaawansowana biblioteka T-Regx do wyrażeń regularnych w PHP

Pozostało 580 znaków

2019-04-29 15:13
3
TomRiddle napisał(a):

Wady dziedziczenia/Zalety kompozycji:

  • Mniejszy coupling klas

Nieprawda - coupling jest inny, ale nie znaczy to, że mniejszy.

  • Można użyć interfejsów: co oznacza możliwość wielu implementacji; zmiany/ustalenia zachowanie w runtime'ie zamiast compile-time, etc.

Czyli błędy zobaczymy w runtime zamiast compile-time.

  • Łatwiejsze testowanie
  • Łatwiejsze mockowanie
  • Łatwiej użyć ponownie już istniejącej logki

To zależy.

  • Łatwiej zmienić kompozycję na np. kontenery DI jak Spring

Bez związku.

  • Jest pierdyliard wzorców projektowych, które wykorzystują kompozycję. Wzorców z dziedziczeniem nie znam żadnych

W takim razie masz duże braki w wiedzy na temat wzorców.

TomRiddle napisał(a):

Niby tak, ale wtedy albo miałby zduplikowane testy, albo musiałby mieć jeden test który testuje np A+Bazową i pozostałe B i C.

Co to jest testowanie klasy bazowej? W klasie bazowej nie ma niczego do testowania, bo nawet nie ma publicznych metod, które można byłoby wywołać.
A jeśli są, to taka klasa nie powinna być bazowa, a więc jest klasą z końca hierarchii i wymaga własnych testów.


"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

Odpowiedz
Liczba odpowiedzi na stronę

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

Robot: Xenu Link Sleuth (4x)