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 23:01
1

@TomRiddle weź pod uwagę kontekst to bardzo ważna rzecz, o której nie pisze się w książkach. Książka jak wykłada Ci zasady pisania kodu to nie podaje kontekstu, przez co wychodzisz z przeświadczeniem, że dana zasada praktycznie sprawdzi się zawsze i wszędzie. Efekt końcowy jest taki, że w pracy albo spotykam syf w stylu kopiuj-wklej albo przeinżynierowane potworki.

Gdy kodujesz nie powinieneś jechać automatycznie na zasadach, regułkach, schematach i orać tym projekt.

Motyw jest taki byś balansował, byś wybierał ciągle mniejsze zło, byś był świadomy gdy łamiesz zasadę, byś oczywiście za jakiś potrafił odkręcić to co robisz, by adaptowac kod do nowych potrzeb itp

Mi w tym przypadku intuicja podpowiada, że w ogóle robienie 15 adapterów coś śmierdzi, zwłaszcza jeśli to nic nie robi tylko przekazuje kod dalej.

Ale zobacz też, gdybyś nam zdradził, że projekt nad jakim pracujesz ma wpływ na zdrowie ludzi to pewnie dostałbyś odwrotne odpowiedzi, że w pewnych przypadkach warto testować zależności, że nawet warto je eliminować jeśli jest taka opcja.

Pozostało 580 znaków

2019-05-10 15:01
0

Jednostkowo - nie ma sensu.
Jako część testu integracyjnego, albo e2e, niejako po drodze - owszem jest. Ale to robisz przy okazji i nie specjalnie celujesz w przetestowanie akurat tego.

Zapomniałem napisać dlaczego:
Dlatego, że to strata czasu, tak samo jak testowanie czy x = y działa poprawnie. Jeśli nie ma w tym logiki to nie ma czego testować jednostkowo.
Testy e2e czy integracyjne testują też za to inne rzeczy - to czy wszystko się ładnie ze sobą spina (żeby nie napisać - integruje). To czy delegacja, wrapper itp działa, to nie tylko kwestia argumentów i wywołań, ale czy działa tam gdzie jest używane ze wszystkim.

Tak samo nie ma sensu testować jednostkowo serwisów, które robią tylko łańcuch wywołań. Za wiele z tego korzyści nie ma. Za to test integracyjny w jakiejś formie da Ci o wiele więcej wartości i owszem jest potrzebny. To w jakiej formie czy e2e, czy na poziomie jakiegoś modułu - to zależy od kontekstu czy monolit czy mikroserwis itd itp.


edytowany 1x, ostatnio: AreQrm, 2019-05-10 15:06

Pozostało 580 znaków

2019-05-13 12:18
0
jarekr000000 napisał(a):
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.

I tu wg mnie jest zawarta cała esencja.
Nie testuj adapterów. To nie ma sensu. One nie mają w sobie niczego do testowania. Zależą od jakichś zewnętrznych zasobów. To, co powinieneś testować, to klasy używające tych adapterów, np:

public class ClientAdapter
{
    public Client GetClient()
    {
        return api.GetClient();
    }
}

public class MyClass
{
    public string GetClientName()
    {
        return clientAdapter.GetClient().GetName();
    }
}

I teraz powinieneś zamockować tutaj ClientAdapter i testowac metodę GetClientName. Powinieneś zrobić przynajmniej dwa testy. GetClient - nie zwrócił niczego; GetClient zwrócić poprawny wynik.
Potraktuj te adaptery jako źródło danych. Nie testuje się źródła danych jednostkowo.

Pozostało 580 znaków

2019-05-13 14:20
3

Przede wszystkim powinno nie testować się kodu dla samego testowania kodu, a testować jakieś zachowania. Efekt końcowy, a nie tylko to czy funkcja została wywołana


Spring? Ja tam wole mieć kontrole nad kodem ᕙ(ꔢ)ᕗ

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