To wyjaśnia, dlaczego powinieneś przeprowadzać testy jednostkowe.
Poniższe 3 filmy dotyczą testów jednostkowych w javascript, ale ogólne zasady obowiązują w większości języków.
Testy jednostkowe: minuty później pozwolą zaoszczędzić godziny później - Eric Mann - https://www.youtube.com/watch?v=_UmmaPe8Bzc
JS Unit Testing (bardzo dobrze) - https://www.youtube.com/watch?v=-IYqgx8JxlU
Pisanie testowalnego JavaScript - https://www.youtube.com/watch?v=OzjogCFO4Zo
Teraz uczę się na ten temat, więc może nie jestem w 100% poprawny i jest w tym coś więcej niż to, co tu opisuję, ale moje podstawowe rozumienie testów jednostkowych polega na tym, że piszesz kod testowy (który jest oddzielony od twojego kod główny), który wywołuje funkcję w kodzie głównym z danymi wejściowymi (argumentami) wymaganymi przez funkcję, a następnie kod sprawdza, czy zwraca prawidłową wartość zwracaną. Jeśli zwróci prawidłową wartość, środowisko testów jednostkowych, którego używasz do uruchomienia testów, pokazuje zielone światło (wszystko dobre), jeśli wartość jest nieprawidłowa, dostajesz czerwone światło, a następnie możesz natychmiast rozwiązać problem wypuść nowy kod do wersji produkcyjnej, bez testowania być może nie zauważyłeś błędu.
Więc piszesz testy dla swojego obecnego kodu i tworzysz kod tak, aby zdał test. Miesiące później ty lub ktoś inny musisz zmodyfikować funkcję w głównym kodzie, ponieważ wcześniej napisałeś już kod testowy dla tej funkcji, teraz uruchom ponownie i test może się nie powieść, ponieważ koder wprowadził błąd logiczny w funkcji lub zwrócił coś całkowicie różni się od tego, co ta funkcja ma zwrócić. Ponownie bez przeprowadzonego testu błąd ten może być trudny do wyśledzenia, ponieważ może również wpłynąć na inny kod i pozostanie niezauważony.
Również fakt, że masz program komputerowy, który uruchamia Twój kod i testuje go, zamiast ręcznie robić to na stronie przeglądarki według strony, oszczędza czas (testowanie jednostkowe dla javascript). Powiedzmy, że modyfikujesz funkcję używaną przez jakiś skrypt na stronie internetowej i działa ona dobrze i dobrze w nowym celu. Ale powiedzmy również dla argumentów, że istnieje inna funkcja, którą masz gdzieś w kodzie, która zależy od tej nowo zmodyfikowanej funkcji, aby działała poprawnie. Ta zależna funkcja może teraz przestać działać z powodu zmian wprowadzonych w pierwszej funkcji, jednak bez przeprowadzonych testów uruchamianych automatycznie przez komputer nie zauważysz problemu z tą funkcją, dopóki nie zostanie ona faktycznie wykonana i ty'
Powtarzając, testy przeprowadzane podczas tworzenia aplikacji wychwycą tego rodzaju problemy podczas pisania. Nie mając testów, musisz ręcznie przejrzeć całą aplikację, a nawet wtedy może być trudno wykryć błąd, naiwnie wysyłasz go do produkcji, a po chwili miły użytkownik wysyła Ci raport o błędzie (który nie będzie tak dobry, jak komunikaty o błędach w środowisku testowym).
To dość mylące, kiedy po raz pierwszy słyszysz ten temat i zastanawiasz się, czy już nie testuję mojego kodu? A kod, który napisałeś, działa już tak, jak powinien, „dlaczego potrzebuję innej struktury?”… Tak, już testujesz swój kod, ale komputer lepiej to robi. Musisz tylko napisać wystarczająco dobre testy dla funkcji / jednostki kodu, a resztę zajmie się tobą potężna jednostka centralna, zamiast ręcznie sprawdzać, czy cały kod nadal działa, gdy wprowadzasz zmiany w Twój kod.
Nie musisz też testować kodu jednostkowo, jeśli nie chcesz, ale to się opłaca, gdy baza projektu / kodu zaczyna rosnąć wraz ze wzrostem szansy na wprowadzenie błędów.