Jak wdrożyć mikrofrontendy w banku? Rozmowa z Jakubem Pawlakiem

[@seNick7]

Wszystko fajnie, ale przy sekcji "testing" widzę rozjazd z trendami. DORA metrics mówi jasno, im częściej i szybciej wdrażasz na produkcję, tym większa jest jakość. A tu padło stwierdzenie, że trwa to długo, bo testerzy sprawdzają. Dlaczego nie ma zaufania w automatycznych testach akceptacyjnych? Dlaczego nie ma shift-left? Dlaczego mowa jest o rozbudowywaniu testów end-to-end, skoro od dawna wiadomo, że jest to zła praktyka? Odpowiedź na te pytania jest prosta: testy frontendu to ciągle terra incognita. Unit testy bardzo często nie dają wartości, a nawet obniżają prędkość developmentu (a powinny podnosić). End-to-endy są flaky i za grosz nie można mieć do nich zaufania. Chciałoby się robić TDD na froncie, ale założeniem TDD jest to, że można refactorować kod, a testy się nie zmieniają.

[@frontendarchitecture]

Hej, dzięki za bardzo fajny komentarz! :) w tym konkretnym przypadku mówimy o testowaniu apki z sektora bankowego. Tam takie rzeczy po prostu trwają. I nie chodzi tutaj tylko o przetestowanie przez testerów poprawności kodu, bardziej chodzi o procesy, czy nic się nie zepsuło itd. W bankach błędy mogą na prawdę sporo kosztować i wydaje mi się, że jest to jeden z powodów dla którego gruntownie testują zmiany. Jak wypuścisz błąd w sieci społecznościowej to najwyżej ktoś zobaczy coś czego nie powinien. W przypadku banku czy ogólnie instytucji finansowych sprawa jest trochę inna. Tutaj nawet jakbyś miał pokrycie testami 100% to i tak biznes będzie chciał to samemu przetestować. Może się to kiedyś zmieni, ale tam takie zmiany potrafią trwać dziesięciolecia :) Zresztą są sektory w których trzeba bardzo dokładnie testować (np medycyna w przypadku tworzenia urządzeń zagrażających życiu). To że ktoś mówi, że się tak powinno robić to zawsze trzeba się zastanowić czy w naszym konkretnym przypadku będzie miało to sens :)

[@seNick7]

@@frontendarchitecture Continuous Delivery i TDD zwłaszcza są potrzebne w instytucjach dużego ryzyka (banki, elektrownie, govy). Tak działa ING - "bank in a box" - testowanie skonteneryzowanych serwisów. Świetnie to pokazał Marcin Pakulnicki na konferencji GOTO ("Death Of The Spotify Model"). Świetnie też to pokazuje Dave Farley (autor THE book Continuous Delivery) w swojej serii o testach akceptacyjnych na KZbin. Tylko że oni działali "od środka" tych instytucji, zmieniając biznes tak, aby rozumiał, że wdrażając coś co 2 dni na produkcję jest mniejsze ryzyko niż big bang dziesiątków featuresów na raz. Ale żeby to robić, trzeba mieć pełną automatyzację, której się ufa i testy kontraktowe. (z naszego podwórka świetnie mówi o tym Jakub Nabrdalik)