Nawet najlepszym programistom zdarzają się dni, w których pisanie testów wydaje się zbędnym narzutem pracy. Na pewno masz takie dni na swoim koncie. Zastanawiam się, jakich wymówek wtedy używasz. Może jednej z tych:


1. Trzeba szybko wypchnąć to na produkcję.

Po co testować, skoro ma szansę zadziałać? Kiedy na produkcji pojawia się problem, albo kończy się sprint, pojawia się presja, żeby dowozić szybciej. Kierując się zasadą Pareta, uznajemy testy za najlepszych kandydatów do pominięcia. Prawda jest jednak taka, że właściwe testy są lepszym pomysłem, niż dobry design kodu. Wypuszczenie otestowanego kodu bez refaktoryzacji jest dużo bezpieczniejsze, niż najlepsza architektura bez testów. Nie bez powodu faza refactor jest po fazie green w procesie TDD.


2. Szybciej jest przetestować manualnie.

Zazwyczaj to jest prawda. Jednorazowo jest nawet taniej! Tylko, czy będziesz testować to za każdym razem, kiedy kod idzie na produkcję? Żyjemy w czasach, kiedy większość firm ma sprawne procesy Continuous Deployment i wypycha zmiany od kilku do kilkudziesięciu razy dziennie. Jak teraz wygląda bilans zysków i strat


3. To problem testerów.

Klasyczne przerzucenie odpowiedzialności za płot. W niektórych zespołach panuje niestety przekonanie, że jakość jest odpowiedzialnością… tych od jakości. Nawet jeśli masz najlepszy zespół QA, to Ty wiesz jakie zmiany właśnie wprowadzasz i jakie testy będą dla nich właściwe. Każdy może mieć gorszy dzień albo większą presję. Tym kimś może być dzisiaj osoba, która testuje Twoje zmiany.

Jeśli chcesz sprawdzić inne wymówki, polecam Ci ten artykuł. Śmiałam się wiele razy 😉

 

Categories: Wyzwania