[Rubajticos]

Jeśli mamy interfejs i jego dwie implementacje to unit testy piszemy dla każdej osobno czy powinno się je jakoś połączyć (te same testy dla obu)

#programowanie #java

[ly000]

@Rubajticos: ofc. osobno, bo niby dlaczego razem?

[chaddeveloper]

@Rubajticos: osobno. Jednak po to piszesz dwie implementacje, maja byc rozne co nie?

Ew mozesz napisac test tego interfejsu i zmieniac klase w zaleznosci od testu.

Tzn masz GetUserInterfaceTest

[Saly]

@Rubajticos: jak testy są takie same to znaczy, że obie klasy robią tak samo, więc wystarczy jedną usunąć xd Jak testy mają jakąś część wspólną to możesz ją wyciągnać do pomocniczych metod.
Co do unitów to piszesz je tylko wtedy, gdy chcesz przetestować jakiś kawałek kodu w izolacji. Jak dana klasa jest używana tylko przez inną klasą to jest duża szansa, że lepiej przetestować tylko nią

[Rubajticos]

@ly000: Tak właśnie robię tylko mnie taka rozkmina dziś naszła, że może lepiej "to zależy" bo:

a) Interfejs typu StringFormatter może mieć implementacje typu CamelFormatter i lowerCaseFormatter i tutaj jasne że będą one zwracać inne wyniki więc i testy różne.
b) Interfejs typu DeviceManager i implementacje per producent no i tutaj już chcemy żeby wyniki zawsze były takie same tylko pod spodem ten sam efekt osiągamy w inny sposób więc

[Saly]

nterfejs typu DeviceManager i implementacje per producent no i tutaj już chcemy żeby wyniki zawsze były takie same tylko pod spodem ten sam efekt osiągamy w inny sposób więc testy mógłyby być wspólne. Chociaż w sumie różne zależności w tych implementacjach to dalej już różne testy ( ͡° ͜ʖ ͡°)

@Rubajticos: różny input, równy output, Możesz to wyabstrachować jak chcesz np. za pomocą zmiennej trzymającej wynik

[Rubajticos]

@Saly: Masz rację, to zdecydowanie ma sens no i teraz tak myślę, że jeśli dana implementacja do osiągnięcia tego samego efektu z kontraktu potrzebuje zrobić coś więcej niż inna to mogą dojść specyficzne dla niej dodatkowe testy. Wtedy byłoby trochę wspólnych, trochę indywidualnych. Faktycznie kiepsko

[Saly]

@Rubajticos: co do testowania to polecam ten artykuł https://mtlynch.io/good-developers-bad-tests/ żeby złapać trochę inną perspektywę

[MQs]

@Rubajticos: Nie ma zasady, ale rzadko jesteś w stanie testować sam kontrakt, kiedy wystarczyłoby zrobić jedną klasę z testami i abstrakcyjne factory methods dla implementacji.
Zwykle na przeszkodzie staną weryfikacje efektów zewnętrznych względem klasy (mocków), które są ściśle z implementacją związane. Można kombinować, ale ciężko robić to konsekwentnie samemu a co dopiero w zespole (który nie koniecznie pracuje zespołowo).

[Krolik]

@Saly: jeżeli testy nie miałyby żadnej części wspólnej to po co wspólny interfejs? Interfejs zawsze definiuje jakiś kontrakt. Dlatego powinieneś mieć testy testujące ten kontrakt dla wszystkich implementacji - testy powinny być wspólne, ale uruchamiane dla każdej implementacji osobno. W ten sposób od razu wyjdzie jeśli implementacje nie spełniają LSP. Natomiast osobne testy musisz mieć tylko dla tych kwestii ktore są rozszerzone przez implementację. Np. jeśli masz implementację która dokłada

[Krolik]

@Rubajticos: przy StringFormatter też możesz mieć trochę testow wspólnych. Np. testy czy formatter poradzi sobie absolutnie z każdym stringiem. Albo może masz załozenie w interfejsie że tekst wyniku będzie zawsze tej samej długości co tekst na wyjściuitp. Albo że dla pustego stringa ma być pusty string na wyjściu.

[Rubajticos]

@Krolik: Ano też prawda. A jakie masz podejście do tworzenia takich wspólnych? Przykładowo tworzymy drugą implementację. Kopiujemy do jej klasy testowej te testy, które są wspólne i zostawiamy wywołanie + asercje i ewentualnie dostosowujemy mocki itp?

[Saly]

@Krolik: jak przetestujesz parę implementacji implementujących javowe Runnable albo Callable?

[Krolik]

@Saly: w przypadku takich ogólnych interfejsów to faktycznie nie ma sensu. Ale to w ogóle nie powinny być interfejsy, a zwykłe funkcje. Interfejsami są tylko dlatego że Java nie umie w FP.

[Rubajticos]

@Krolik: FP?

[Krolik]

@Rubajticos: programowanie funkcyjne