„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 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? Pewnie 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 testach Systemu 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 bezpieczeństwa i okiełznania chaosu zduplikuje przypadki testowe. Po to by na wielgachnym systemie na siódmej stronie formularza spróbować wpisać imię o jeden znak za długie. Nie ma to jak drogi zestaw testów który jest stabilnie czerwony. Aj… przestań już! Boli! Chaos! Z tym testowaniem to już tak jest. jUnit jest prosty, AssertJ również, Mockito, 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.