DevEnv
2019-02-15 13:28

Dev:Cast – Unit Tests – Dobre praktyki
Testy jednostkowe to temat, który nie raz poruszaliśmy podczas naszego podcastu. Wspominaliśmy o ich wartości, głównych zasadach ale także zachwalaliśmy technikę Test-driven development. Z naszych rozmów jednoznacznie wynika, że praca bez Unit Tests jest dla nas ciężka i tak na prawdę zwiększa ilość pracy…

Tym razem skupiliśmy się na definicji kilku dobrych praktyk wspomagających tworzenie testów jednostkowych. Takich testów, które dobrze weryfikują implementacje, zapewniają jakość oraz łatwo jest je utrzymywać.

#devenv #devcast #programowanie #dobrepraktyki #unittests #technicalblog

lubie_programowac

"Dzwony dzwonią ale nie wiadomo w którym kościele" - tutaj prezentujecie inne podejście https://www.spreaker.com/user/devenv/devcast-06 ~4:25 "Mieliśmy dużą ilość testów na różnych poziomach którym kompletnie nie był w stanie zaufać. Nie były deterministyczne. [...] Spotykasz dużą ilość testów, sam brak nie musi być rzeczą negatywną bo ich nadmierna ilość albo ich wadliwa jakość też może nie być dobra dokumentacją projektu. " Pragmatyzm ponad dogmatyzmem - tzn KPI / cel aby osiągnąć 100% test coverage nie jest dobrym. Dobry programista pisze dobre testy, tworzy dobrą architekturą, tworzy dobry design.

Aventus

Osobiście jestem zdania że testy jednostkowe należy ograniczyć do minimum, tam gdzie naprawdę maja one sens. Np. mam jakąś klasę enkapsulujacą operacje na czasie, wtedy chce ja oddzielnie pokryć testami jednostkowymi aby sprawdzić każdy przypadek użycia. W każdym innym razie zdaje się na testowanie konkretnego scenariusza w obrębie danej aplikacji/serwisu. Podmieniam zewnętrzne zależności (inne serwisy, bazy danych itp.) natomiast (zakładając aplikację webową) w teście stawiam wirtualny host, wykonuje jakiś request i sprawdzam wynik. W ten sposób testowany jest cały pipeline danej operacji. Osiągam te same profity co przy użyciu testów jednostkowych, ale bez niepotrzebnego rozdrabniania się i kilku/kilkunastu testów wyrwanych z kontekstu, w miejsce jednego który właśnie tenże kontekst testuje.

danek

@Aventus: ale tracisz na tym czas

danek

@Aventus: ideą testów jednostkowych jest to, że w ciągu ~1-2 sekund masz wynik czy cała Twoja logika biznesowa działa jak powinna, robiąc to co mówisz trwa to chyba dłużej, nie?

Aventus

@danek: pierwsze słyszę o takiej idei testów jednostkowych. No ale nie będę się czepiał szczegółów, domyślam się o co Ci chodzi. Natomiast nie wierzę w to że przy bardziej rozbudowanej logice wszystkie testy jednostkowe wykonują się w 1-2 sekundy. Faktycznie, testy które opisałem są wolniejsze, ale nieznacznie. To nie są pełnoprawne testy integracyjne a kompromis- coś za coś. Ponadto, jestem przekonany że znacznie zaoszczędza się na czasie przy pisaniu nowych testów, ponieważ nie muszę się rozdrabniać dla każdej nowo napisanej "jednostki". Jeśli nowa funkcjonalność jest w ramach już istniejącej, pokrytej testami to w ogóle nie ma potrzeby na pisanie nowych testów.

danek

@Aventus: zależy co dla ciebie jest jednostką. U siebie odpalam cała aplikacje bez I/O podczas testów z zmockowana baza jako hashmape i mam efekt podobny do ciebie tylko szybszy. Odpowiednie formatowanie przez kontrolery itp ogarniam sobie osobnymi 'integracyknymi' testami odpalamymi rzadziej