W dużym projekcie nie da się pamiętać, że gdzieś już jest funkcja licząca to samo – więc pisze się ją drugi i trzeci raz. To nie lenistwo, to koszt pamięci. Problem w tym, że kopie z czasem się rozchodzą: ta sama najlepsza próba ucznia potrafiła być inna na ekranie i w PDF-ie, a w aplikacji mobilnej ten sam egzamin pokazywał czas raz jako 12:05, raz jako 12 min 5 s. Ta sama choroba złapała niezależnie backend Django i aplikację w React Native. O tym, dlaczego duplikacja to fabryka takich rozjazdów, i jak posprzątać ją bezpiecznie: najpierw dopisać testy, potem scalać, a zielona suita ma świecić tak samo przed i po.
Teza krąży po branży od lat: gdyby programiści porządnie testowali własny kod, testerzy byliby zbędni. Patrzę na nią z nietypowej pozycji, bo jestem programistą po studiach podyplomowych z testowania – i rozkładam ją na łopatki trzema argumentami: moje testy testują moją wyobraźnię, tester patrzy na aplikację inaczej niż ja, a testowanie to zawód z własnym warsztatem. Z uczciwym rozdziałem o tym, co się w tej tezie mimo wszystko broni.
Po serii o testowaniu czas na dowód z produkcji, policzony co do sztuki: backend Django z ponad 100 tysiącami linii kodu i 6,6 tysiąca testów, mobilka React Native z 44 tysiącami linii i ponad 1600 testami, do tego 298 testów Playwright, 7 przepływów Maestro i bramka w GitHub Actions, która nie raz zatrzymała zepsute wdrożenie przed produkcją. Z metodą liczenia, proporcjami kodu do testów i uczciwym rozdziałem o tym, czego wciąż nie pokrywam.
Testy end-to-end miały u mnie zasłużenie złą opinię: Selenium z ręcznymi sleepami i łamliwymi XPathami, Appium z konfiguracją trudniejszą niż same testy. Dlatego latami ich unikałem – i to był błąd, tylko że wtedy racjonalny. Dziś flow na webie klika Playwright, a na mobile Maestro w kilkunastu linijkach YAML-a. Co konkretnie się zmieniło, tabela stare kontra dziś i uczciwy rozdział o tym, czemu E2E wciąż jest drogie.
Skoro testować, to co dokładnie i na którym poziomie? Piramida testów opowiedziana po ludzku: testy jednostkowe w pytest, integracyjne z bazą i widokami Django, testy przepływów na samej górze. Skąd naprawdę biorą się luki w pokryciu, dlaczego sto procent pokrycia niczego nie gwarantuje – i dlaczego moje testy pilnują nie tylko kodu, ale też treści tego bloga.
Tytuł jest lekko na wyrost – testy automatyczne piszę od dawna, a z testowania oprogramowania skończyłem nawet studia podyplomowe. Ale pierwszym odruchem po napisaniu kodu przez ponad ćwierć wieku był ręczny klik: działa, wdrażam. O błędach mówiła mi produkcja – logami, użytkownikami albo wcale, gdy funkcja leżała kilka dni i nikt jej nie zgłosił. Historia trzech nakładających się epok jednego nawyku, z uczciwym rozdziałem o tym, czego test-first nie załatwia i kiedy ręczne testowanie wciąż ma sens.
