Czy jest sens testować delegację?

Odpowiedz Nowy wątek
2019-05-09 18:21
0

Mam sobie bardzo OOP kod. Mam też około 15 adapterów, które biorą klasy jakichś libek i nadają im interfejsy javowe. I teraz ich jedyna odpowiedzialność to jest przyjąć parametry i wywołać metodę delegata zwracając wynik - zwykły adapter.

Tylko testowanie takich adapterów jest dosyć mozolne, przez 25 minut napisałem test tylko do jednego. Chodzi o to że nie wystarczy wsadzić stringa 'Foo' i wyciągnąć 'Bar' (tzn, tak by było gdyby parameterm/return-type'm tej metody był String) tylko trzeba tworzyć mocki parameterów wejściowych, i wkładać fabtyki żeby się upewnić czy wychodzi dobra instancja.

No właśnie, niby nie zaszkodzi - ale kto by wszedł do adaptera i usunął albo podmienił kod - w klasie w której nie ma logiki?

No i nie wiem - testować te adaptery czy nie?

Logika wygląda mniej więcej tak

class LibSupplierAdapter<T> implements java.util.Supplier<T> {
    private final org.lib.Supplier<T> supplier;

    public T get() {
        return supplier.get(); // No kto tu przyjdzie i to zmieni?
    }
}

char mander; bool basaur;
Zaawansowana biblioteka T-Regx do wyrażeń regularnych w PHP
edytowany 3x, ostatnio: TomRiddle, 2019-05-09 18:57

Pozostało 580 znaków

2019-05-09 18:38
1

Nie.
Szczególnie jeśli org.lib.Supplier jest generyczny (u Ciebie nie, ale strzelam, że to pomyłka przy wklepywaniu tu).
Zepsucie tego w javie jest możliwe, ale na tyle nienaturalne, że bym odpuścił.

Takie rzeczy są testowane przy okazji testowania innych funkcji.
Warto, żeby coverage raz przeleciał.

Z drugiej strony IMO testowanie tego jest tak trywialne, że w zasadzie to można sobie z nudów zrobić. Ale potrzeby nie ma.
Podobnie w kotlinie nie testuje czy data class działają itp.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 6x, ostatnio: jarekr000000, 2019-05-09 18:43

Pozostało 580 znaków

2019-05-09 18:58
0
jarekr000000 napisał(a):

Podobnie w kotlinie nie testuje czy data class działają itp.

No ale data klasy nie mają faktycznie żadnej logiki. A adaptery, czy to delegacja czy nie to te 1-3 linijki można by klepnąć.


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

Pozostało 580 znaków

2019-05-09 19:29
0

Ja bym nie testował, można ten czas spędzić lepiej.

Pozostało 580 znaków

2019-05-09 19:30
0
Afish napisał(a):

Ja bym nie testował, można ten czas spędzić lepiej.

Zadając to pytanie bardziej spodziewałbym się jakichś argumentów za/przeciw, niż opinii.


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

Pozostało 580 znaków

2019-05-09 19:33
1

No jeżeli dla Ciebie „marnowanie czasu” nie jest argumentem, to nie dojdziemy do konkluzji. Te testy nie dodają nic, jeżeli ktoś miałby tam napsuć, to powinno się to wyłapać innymi testami i przeglądem kodu.

Pozostało 580 znaków

2019-05-09 19:38
0
Afish napisał(a):

No jeżeli dla Ciebie „marnowanie czasu” nie jest argumentem, to nie dojdziemy do konkluzji.

Nie powiedziałeś czemu testowanie tego to miałoby być marnowanie czasu - no ok, "możnaby poświęcić na coś innego". Jeden rabin powie tak, drugi rabin powie że w ogóle testy nie mają sensu bo można go poświęcić inaczej.

Ja się spodziewałem argumentów merytorycznych.

Te testy nie dodają nic, jeżeli ktoś miałby tam napsuć, to powinno się to wyłapać innymi testami i przeglądem kodu.

Czemu nie dodają nic? Gdyby nie dodawały nic - to uwierz - nie poświęciłbym 25 minut na pisanie ich. Te testy testują:

  • To czy adaptery poprawnie oddelegowują zachowanie/parametry/return'y do swoich zależności. Faktycznie, czasem ta delegacja jest bardzo prosta jak w moim przykładzie. Nie znaczy to że nie testują "nic".

Może zredaguję pytanie: Testy testują bardzo mało. Czy to "mało" jest warte swojego czasu i dlaczego?

to powinno się to wyłapać innymi testami i przeglądem kodu.

Może klasy JsonParser też nie będę testował, bo przecież test do HttpClient mu naklepie coverage?

to powinno się to wyłapać innymi testami i przeglądem kodu.

Nie po to piszę testy żeby wyłapywać bugi przeglądaniem kodu.


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

Pozostało 580 znaków

2019-05-09 19:53
0
TomRiddle napisał(a):

Czemu nie dodają nic? Gdyby nie dodawały nic - to uwierz - nie poświęciłbym 25 minut na pisanie ich. Te testy testują:

  • To czy adaptery poprawnie oddelegowują zachowanie/parametry/return'y do swoich zależności. Faktycznie, czasem ta delegacja jest bardzo prosta jak w moim przykładzie. Nie znaczy to że nie testują "nic".

A łapiesz tę delegację gdzieś indziej? Jeżeli nie, to wtedy taki test jest przydatny, ale jeżeli łapiesz (a uważam, że powinieneś), to wtedy ten test nic nie daje. „Nie testuje nic” w sensie „nie testuje nic, co już nie byłoby przetestowane”.

Może zredaguję pytanie: Testy testują bardzo mało. Czy to "mało" jest warte swojego czasu i dlaczego?

Zależy od innych testów, które masz. Jeżeli te inne wyłapią tę interakcję, to moim zdaniem pisanie testów do adapterów jest stratą czasu. Ale jeżeli tych innych nie masz, to może warto byłoby się skupić na tamtych, zamiast testować proste delegacje.

Może klasy JsonParser też nie będę testował, bo przecież test do HttpClient mu naklepie coverage?

Coverage a poprawność to dwie różne sprawy. Poza tym to inna sytuacja, bo testami HttpClient raczej nie testujesz wszystkich możliwych jsonów. Jeżeli byś tak robił, to wtedy testy parsera nie byłyby potrzebne (bo nie dodawałby nic nowego), ale raczej nie byłby to ładny kod.

Nie po to piszę testy żeby wyłapywać bugi przeglądaniem kodu.

Testy nie są jedyną metodą wyłapywania błędów. Poza tym, co będzie, jak ktoś wywali te Twoje testy? Jak to wyłapiesz, jak nie przeglądem kodu (lub automatycznymi metrykami)?

Pozostało 580 znaków

2019-05-09 22:20
1
Afish napisał(a):

Ja bym nie testował, można ten czas spędzić lepiej.

W istocie to jest dobra odpowiedź.

Inżyniera oprogramowania polega też na racjonalnym wykorzystaniu środków.
Jeśli bedziemy testować trywialne rzeczy, to może nie starczyć czasu na ważne.

Dodatkowo. Testowanie wcale nie jest najlepszą formą sprawdzania poprawności programu.
Jest dość ekonomiczną - daje niezłą pewnośc przy małym koszcie. Ale to już ISTOTNE uproszczenie.

Typowe testowanie przypomina trochę dowodzenie na zasadzie - twierdzenie pitagorasa działa dla trójkąta 3,4,5 oraz dla 1,1,sqrt(2) więc musi się zgadzać :-)
Decydując się na Test poddajesz się i wykonujesz (rażące) uproszczenie. Ale takie uproszczenie zwykle wystarcza, bo o ile nie piszemy złośliwego kodu
to zwykle sprawdzenie jednego, dwóch przypadków i przypadków brzegowych wystarcza.

Nieco dokładniej można testować w oparciu o właściwości - czego prawie nikt w javie nie robi. (property based tests)
Można też formalnie dowodzić poprawności fragmentów programu, czego z kolei, jeśli od programu nie zalezy czyjeś życie to raczej się nie robi (za duży koszt, za rzadko coś faktycznie wychodzi).

Jesli mamy dość generyczny kod - jak u Ciebie - to szansa zepsucia jest tak mała, że w zasadzie można pominąć.
IMO wystarczy, że gdzieś jakiś inny test tą funkcję wykorzystuje i już możesz przyjąć, że działa.

Jeśli faktycznie komuś uda się zepsuć, a błąd wyjdzie w teście innej funkcji to i tak szukanie źródła problemu będzie proste.

Przy okazji - badając przykład znalazłem jak to spierniczyć:

 public T get() {
        return new LibSupplierAdapter(supplier).get(); // No kto tu przyjdzie i to zmieni? - ja :-)
    }

Spierniczneie polega na tym, że znalazłem nietrywialną kompilującą się wersję, która nie jest poprawna.
(btw tak się ubija Haskella zwykle - tak zwana dupa: _|_).
Program w javie spierniczyć jezt zwykle dużo trywialniej - return null;, throw new RuntimeException(). Skompiluje się, ale nie zadziała.
Z tym, że takie implementacje zwykle na tyle łatwo wyłapiesz... że naprawdę nie ma co się silić.


Bardzo lubie Singletony, dlatego robię po kilka instancji każdego.
edytowany 10x, ostatnio: jarekr000000, 2019-05-09 22:36
throw null jest chyba najkrótszym uniwersalnym gotowcem. - Wibowit 2019-05-09 22:41

Pozostało 580 znaków

2019-05-09 22:22
0
jarekr000000 napisał(a):
Afish napisał(a):

Ja bym nie testował, można ten czas spędzić lepiej.

W istocie to jest dobra odpowiedź.

but.why.jpg

Cały czas pytam o powód, a dostaję tylko opinie.


char mander; bool basaur;
Zaawansowana biblioteka T-Regx do wyrażeń regularnych w PHP
A mój post to co? Na kiego grzyba to wszystko pisałem? - jarekr000000 2019-05-09 22:30

Pozostało 580 znaków

2019-05-09 22:28
1
TomRiddle napisał(a):

Cały czas pytam o powód, a dostaję tylko opinie.

Podałem Ci już powód — jeżeli jest to przetestowane gdzie indziej, to ten test nic nie dodaje. Ma też sporo wad — jest to kod do napisania, do przejrzenia, do uruchomienia, do utrzymania.

Bycie programistą, to nie (tylko) klepanie kodu, ale dostarczanie wartości biznesowej, rozwiązywanie problemów (wyzwań!) klientów i generowanie kasy. Można testować takie rzeczy, jeżeli klient za to zapłaci, to nawet lepiej, ale ten czas można spędzić na poprawie ważniejszych elementów, uzupełnieniu dokumentacji, wyliczeniu metryk użycia produktu lub zaplanowaniu kolejnej funkcji systemu. Jeżeli adaptery są testowane gdzieś indziej, to dodanie kolejnego testu nie niesie moim zdaniem wystarczającej wartości biznesowej, aby poświęcać na ten proces 25 minut (lub więcej).

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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

Robot: CCBot (2x)