Testowanie kodu to bajka. Strategia taka, że piszesz unity i integration. Tak Ci powiedzieli. Hm, Strategia...

"Aha... Bo widzisz... ja mówię o testach integracyjnych między modułami, a Ty - między komponentami" - Powiedzieli sobie po godzinnej dyskusji nad Code Review. Po kolejnej godzinie okaże się że integracja modułu i komponentu to zupełnie dwie różne bajki. Ale po kolei - najpierw niech dojdą do tego że nie rozumieją nawzajem czym jest moduł a czym komponent.

Czy to naprawdę jest tak że możemy pisać jedynie testy jednostkowe, integracyjne i e2e? No, to czym jest ten unit? A integracyjny to co z czym zintegrowane? A dlaczego to nie unit, skoro też pisze się w jUnit? Czy integracyjny to ten wolny, a unit to ten szybki? Dlaczego w zasadzie mówią aby rozdzielać Logikę Aplikacyjną od logiki domenowej skoro i tak obkładam to testem integracyjnym?

A w e2e końcówkami są wejścia i wyjścia klasy, komponentu, modułu, mikroserwisu, kontraktów czy całego systemu? A to w ogóle mamy jakieś komponenty i moduły? I co zrobi tester? Dla okiełznania chaosu zduplikuje nasze przypadki testowe i na podniesionym wielgachnym systemie na siódmej stronie formularza w automacie spróbuje wpisać imię o jeden znak za długie. Nie ma to jak drogi zestaw testów który jest stabilnie czerwony przez podstawową walidację.

Aj... przestań już! Boli! Chaos!

Z tym testowaniem to już tak jest. jUnit jest prosty, AssertJ również, nawet Spock. Do ogarnięcia tutorialem. I tak zostajemy sami z rozrzuconymi narzędziami. Ale jak to poskładać... sensownie... trzeba by przyjąć jedną ze strategii testowania. Czekaj! to można mieć strategię?! Nawet kilka?... To nie ma jednej słusznej piramidy?! Pokaż!

Pokażę! Ale wyjdźcie z ustalonych ram i przygotujcie się na coś nowego.

🔥 [4Developers 2024] https://eventory.cc/event/4developers...
👉 [FB]   / 4developers  
👉 [LI]   / 4developers