Powiedzmy, że chciałeś ręcznie przetestować aplikację za każdym razem, gdy ją wdrażasz. Jak byś to zrobił?
Na początek możesz sporządzić listę wszystkich rzeczy, które chcesz przetestować, abyś nie zapomniał przetestować czegoś później. Następnie prawdopodobnie napiszesz kroki dla każdego testu, aby upewnić się, że wykonałeś je w ten sam sposób za każdym razem. Jeśli nie upewnisz się, że zastosowany proces testowania był spójny, wyniki nie byłyby spójne.
Teraz, gdy masz już listę testów, które musisz wykonać, otwórz przeglądarkę, przeczytaj kroki pierwszego testu, wykonaj je i zanotuj wynik. Powtórzyłbyś ten proces dla każdego testu na liście.
Liczba przeprowadzanych testów będzie rosła wraz z rozwojem aplikacji i wykrywaniem nowych błędów. Oczywiście ograniczyłbyś się do wykonywania tych testów z ludzką prędkością, co czyni je raczej powolnymi.
Ironia polega na tym, że mechanicznie przeglądając listę operacji, wykonujesz obliczenia. Robisz to po prostu wolniej niż, powiedzmy, komputer.
To, między innymi z wielu dobrych powodów, dlatego piszemy testy jednostkowe: pozwalają komputerowi wykonywać obliczenia, więc nie musisz.
Potrafię uruchomić kompleksowy pakiet testów jednostkowych wystarczająco szybko, aby używać go często podczas programowania, a nie tylko raz w tygodniu przed wdrożeniem. Pozwala mi to szybciej wykrywać błędy, oszczędzając czas i pieniądze.
Mogę nawet pisać testy, które przewidują zachowanie systemu, a następnie zapisywać to zachowanie (które już wiem, że jest poprawne, ponieważ właśnie go przetestowałem), proces znany pod nazwą Test Driven Development.