Nawet ja rozumiem, iż nie zawsze da się pisać testy. To znaczy, tak byłoby najlepiej, ale życie nie zawsze jest takie kolorowe. Przez sytuację w projekcie albo swoje umiejętności czasem może być trudno. Wtedy zadaj sobie pytanie, czy nie jesteś w jednej z tych sytuacji:
1. Musisz się „bronić” przed innymi zespołami. jeżeli pracujesz w większym projekcie to na pewno są takie części systemu, które wpływają na Twój kod. jeżeli go nie zabezpieczysz przed niechcianymi zmianami, gwałtownie możesz ponieść konsekwencje cudzych działań. Możesz wykorzystać testy kontraktowe, albo inne testy integracyjne, które będą stały na straży.
2. Nie rozumiesz co Twój kod tak naprawdę ma robić. Niby masz wszystkie składniki, wiesz jakich bibliotek użyć, co wysłać do bazy, jaki endpoint stworzyć. Ale co to ma tak naprawdę robić? Testy pomogą Ci to zrozumieć. Nie wierzysz? W testach musisz skupić się nad tym co tak naprawdę chcesz przetestować. Żeby je napisać musisz to dobrze zrozumieć. Zdobywasz wiedzę o domenie, a przy okazji powstają testy. Profit.
3. Kod jest najważniejszy dla działania systemu. Może tutaj chodzić o dostępność jakiegoś serwisu, albo kluczową logikę biznesową. Bez względu na to, czy to kluczowość techniczna czy biznesowa, chcesz mieć pewność, iż wprowadzając zmiany nie zepsujesz niczego w tym kodzie, prawda? Dodaj tam testy. Na różnych poziomach. Niech wychwycenie regresji nie jest zdane na testy manuale i łut szczęścia, od tego są testy automatyczne.
Jeśli będziesz pisać testy wyłącznie w tych sytuacjach, gwałtownie docenisz ich plusy i zechcesz pisać je wszędzie. Jak dzisiaj na Twitterze Jarosław: „Niepisanie testów jest bez sensu”. To był komentarz do mojego vloga właśnie na ten temat i zrobiło mi to dzień
