Testy jednostkowe klasy dziedziczącej po klasie bazowej

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

Rejestracja: 17 lat temu

Ostatnio: 4 dni temu

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
Moderator

Rejestracja: 12 lat temu

Ostatnio: 3 minuty temu

Lokalizacja: Wrocław

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

Rejestracja: 17 lat temu

Ostatnio: 4 dni temu

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

Rejestracja: 10 lat temu

Ostatnio: 6 godzin temu

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).


edytowany 1x, ostatnio: TomRiddle, 2019-04-29 11:29

Pozostało 580 znaków

2019-04-29 11:46

Rejestracja: 17 lat temu

Ostatnio: 4 dni temu

0

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

Pozostało 580 znaków

2019-04-29 12:07

Rejestracja: 1 rok temu

Ostatnio: 1 rok temu

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

Rejestracja: 17 lat temu

Ostatnio: 4 dni temu

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

Rejestracja: 10 lat temu

Ostatnio: 6 godzin temu

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.


edytowany 6x, ostatnio: TomRiddle, 2019-04-29 15:12

Pozostało 580 znaków

2019-04-29 15:07
Moderator

Rejestracja: 12 lat temu

Ostatnio: 6 godzin temu

Lokalizacja: Wrocław

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

Rejestracja: 10 lat temu

Ostatnio: 6 godzin temu

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.


Pozostało 580 znaków

2019-04-29 15:13
Moderator

Rejestracja: 12 lat temu

Ostatnio: 6 godzin temu

Lokalizacja: Wrocław

4
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

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