sobota, 3 października 2015

Czasami (czasami często) słyszę, że:

...ktoś nie napisał testu jednostkowego bo nie miał na to czasu.

Gdy to słyszę to aż bolą mnie zęby.

Jak można nie mieć czasu na sprawdzenie czy nasz kod działa poprawnie?

Wtedy zawsze staram się wyjaśnić, że:

... ja nie mam czasu nie pisać testów jednostkowych.

Nie mam czasu marnować czas na uruchomienie całego środowiska i wykonania wszystkich kliknięć w aplikacji aby sprawdzić czy przed chwilą napisany kawałek kodu działa zgodnie z moimi oczekiwaniami.

Załóżmy że: w przeszłości nie miałeś wystarczająco dużo czasu na napisanie testu jednostkowego aby sprawdzić czy aplikacja działa poprawnie. Przeklikałeś aplikację i z większym lub mniejszym strachem powiedziałeś, że działa.

Załużmy teraz że: w przyszłości, zmieniłeś kod w taki sposób, że obawiasz się czy kilka poprzednich funkcjonalności nadal działa poprawnie. Musisz teraz przeklikać wszystkie te przypadki użycia w ramach tych newralgicznych funkcjonalności.

A gdybyś: poświęcił czas na napisanie testu jednostkowego zamiast poświęcić go na klikanie to w przyszłości nie poświęciłbyś ani sekundy na ponowne klikanie - testy jednostkowe sprawdziłby ten kod za ciebie. Nie ma strachu o błędy regresyjne.

Tak zaoszczędzony czas pozwoli ci na napisanie więcej nowych funkcjonalności z testami jednostkowymi, na które nigdy nie miałeś czasu bo musiałeś klikać po aplikacji.

Nie wszędzie, ale może tak być, że zarząd się ani nie ucieszy, ani ucieszy, gdy będziesz się chwalić, że przetestowałeś swój kod testami jednostkowymi. Zarząd może kompletnie nie kminić o co ci chodzi.

Ale jeśli powiesz, że teraz możesz pisać więcej funkcjonalności w tym samym czasie z mniejszą liczbą błędów to nie wszędzie, ale może tak być, że Cię przynajmniej pochwalą.

Każde takie manualne przetestowanie aplikacji zaraz po najbliższej zmianie kodu jest nic nie warte. Po każdej zmianie kodu czas poświęcony na manualne przetestowanie wyrzucany jest do kosza. Czas, który włożyliśmy w manualne testowanie nigdy już w przyszłości nam się nie zwróci. Czas ten jest czasem bezpowrotnie zmarnowanym.

Więc jeśli mamy mało czasu (a zawsze mamy go mało) to oszczędzajmy go pisząc test jednostkowy, zamiast trwonić go robiąc testy manualne.

Napisanie testu jednostkowego jest o wiele szybsze od wielokrotnego przeklikiwania aplikacji na nowo po każdej zmianie. Czas włożony w stworzenie testu jednostkowego, będzie nam się zawsze zwracał, przez cały czas trwania projektu.

Zmiast szastać czasem na klikanie po aplikacji w celu jej przetestowania, ten sam czas wykorzystaj na napisanie testu jednostkowego. Jeśli poświęcisz tyle samo czasu na pisanie testu jednostkowego ile potrzebowałbyś przeznaczyć na uruchomienie aplikacji i wykonanie scenariusza testowego manualnie, już zaoszczędziłeś czas. Pisząc test jednostkowy będziesz mógł wykonywać ten sam test wiele razy w przyszłości, nie poświęcając na niego ani sekundy.

No i oczywiście jest WIELE innych zalet pisania testów jednostkowych takich jak na przykład wymuszenie na programiście pisania kodu obiektowego. Ale nie o tym tutaj w tym poście... W tym poście opisuje sytuację gdy nie ma czasu na nic, więc na obiektowość też nie ma czasu :).
 
Gdy nie masz na nic czasu to radzę zacząć pisać testy jednostkowe aby ten czas sobie zaoszczędzić.
 
 




5 komentarzy :

  1. troche trudno mi sie zgodzić z jednym stwierdzeniem - test jednostkowy zastąpi testy manualne. Otóż nie - w tym celu stosuje sie innego rodzaju testy - tzw testy integracyjne a w idealnym przypadku testy akceptacyjne które weryfikują konkretne sceanriusze użycia aplikacji. Testy jednostkowe weryfikują zgodność implementacji z jej zalozeniami a prawidlłowe zachowanie calego systemu testuje sie testami akceptacyjnymi(można np stosować BDD w tym celu)

    OdpowiedzUsuń
  2. Masz rację. Pisząc tego posta nie miałem zamiaru odradzać wykonywania testów manualnych wtedy gdy są potrzebne. Moją intencją jest zwrócenie uwagi na sytuacje, w których testuje się manualnie a powinno się napisać test jednostkowy. Zgadzam się, że całość systemu należy uruchomić i wykonać niezbędne scenariusze przypadków użycia w celu wykonania testów integracyjnych. Odradzam wykonywanie testów manualnych w celu sprawdzania czy dana metoda, którą napisaliśmy zachowuje się tak jak oczekujemy lub aby sprawdzić czy nie zepsuliśmy tego co już było. Zamiast w nieskończoność klikać po aplikacji po każdej zmianie kodu lepiej napisać test jednostkowy. P.S. W przypadku BDD w narzędziu SpecFlow, w tle odpalane są testy jednostkowe, generowane automatycznie na podstawie scenariuszy.

    OdpowiedzUsuń
  3. Wiesz pisać testy a uruchamiać testy to jest duuża różnica :)
    Pozdrawiam :)

    OdpowiedzUsuń
  4. W domyśle mam to, że testy jednostkowe powinny być odpalane po każdym uaktualnieniu repozytorium z automatu.

    OdpowiedzUsuń