Bartosz Bryniarski

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.

0,1 + 0,2 to nie 0,3 – a to znaczy, że typu float nie wolno używać do pieniędzy. Nie chodzi o ostrożniejsze zaokrąglanie, tylko o inny typ danych. Przegląd tego, jak liczy się kwoty poprawnie: grosze jako liczby całkowite, DECIMAL w bazie, decimal w Pythonie, BigDecimal w Javie, BCMath w PHP i BigInt w JavaScripcie. Do tego zaokrąglenie bankierskie i słynny spór o VAT liczony od pozycji czy od sumy.