Co to są testy jednostkowe? [Zamknięte]

Widziałem wiele pytań z pytaniem „jak”, aby przeprowadzić test jednostkowy w określonym języku, ale bez pytania „co”, „dlaczego” i „kiedy”.

• Co to jest?
• Co to dla mnie robi?
• Dlaczego powinienem tego używać?
• Kiedy powinienem go używać (także kiedy nie)?
• Jakie są typowe pułapki i nieporozumienia

Testy jednostkowe to z grubsza testowanie bitów kodu w oderwaniu od kodu testowego. Bezpośrednie zalety, które przychodzą na myśl, to:

• Przeprowadzanie testów staje się automatyczne i powtarzalne
• Możesz testować na dużo bardziej szczegółowym poziomie niż testowanie za pomocą interfejsu GUI

Pamiętaj, że jeśli kod testowy zapisuje do pliku, otwiera połączenie z bazą danych lub robi coś przez sieć, jest bardziej odpowiednio klasyfikowany jako test integracyjny. Testy integracyjne są dobrą rzeczą, ale nie należy ich mylić z testami jednostkowymi. Kod testu jednostkowego powinien być krótki, słodki i szybki do wykonania.

Innym sposobem spojrzenia na testy jednostkowe jest napisanie testów jako pierwszych. Jest to znane jako Test-Driven Development (w skrócie TDD). TDD ma dodatkowe zalety:

• Nie piszesz spekulatywnego kodu „Mogę tego potrzebować w przyszłości” - wystarczy, aby testy przebiegły pomyślnie
• Napisany kod jest zawsze objęty testami
• Pisząc najpierw test, musisz zastanowić się, jak chcesz wywołać kod, co zwykle poprawia jego konstrukcję na dłuższą metę.

Jeśli nie przeprowadzasz teraz testów jednostkowych, zalecamy rozpoczęcie pracy. Zdobądź dobrą książkę, praktycznie zrobi to każda książka xUnit, ponieważ koncepcje są bardzo łatwe do przeniesienia między nimi.

Czasami pisanie testów jednostkowych może być bolesne. Kiedy tak się stanie, spróbuj znaleźć kogoś, kto ci pomoże, i oprzyj się pokusie „po prostu napisać ten cholerny kod”. Testy jednostkowe przypominają mycie naczyń. Nie zawsze jest przyjemnie, ale utrzymuje czystość twojej metaforycznej kuchni i naprawdę chcesz, aby była czysta. :)

Edycja: przychodzi mi na myśl jedno nieporozumienie, chociaż nie jestem pewien, czy jest to tak powszechne. Słyszałem, jak kierownik projektu powiedział, że testy jednostkowe zmusiły zespół do napisania całego kodu dwa razy. Jeśli tak wygląda i czuje, to robisz to źle. Pisanie testów zwykle nie tylko przyspiesza programowanie, ale także daje wygodny wskaźnik „teraz gotowe”, którego inaczej byś nie miał.

Nie zgadzam się z Danem (chociaż lepszym wyborem może być po prostu nie odpowiadać) ... ale ...

Testowanie jednostkowe to proces pisania kodu w celu przetestowania zachowania i funkcjonalności systemu.

Oczywiście testy poprawiają jakość twojego kodu, ale to tylko powierzchowna korzyść z testów jednostkowych. Prawdziwe korzyści to:

1. Ułatwienie zmiany implementacji technicznej przy jednoczesnym upewnieniu się, że nie zmienisz zachowania (refaktoryzacja). Prawidłowo przetestowany kod jednostki może być agresywnie refaktoryzowany / wyczyszczony z niewielką szansą na uszkodzenie dowolnego elementu bez zauważenia go.
2. Daj programistom pewność podczas dodawania zachowań lub poprawek.
3. Udokumentuj swój kod
4. Wskaż obszary swojego kodu, które są ściśle powiązane. Trudno jest jednoznacznie powiązać kod testowy z jednostką
5. Zapewnij sposób korzystania z interfejsu API i wczesnego szukania trudności
6. Wskazuje metody i klasy, które nie są zbyt spójne

Należy przeprowadzić test jednostkowy, ponieważ w jego interesie jest dostarczenie klientowi produktu o wysokiej jakości, który można utrzymać.

Sugerowałbym, aby użyć go do dowolnego systemu lub jego części, która modeluje zachowanie w świecie rzeczywistym. Innymi słowy, szczególnie dobrze nadaje się do rozwoju przedsiębiorstwa. Nie użyłbym tego do programów wyrzucania / użyteczności. Nie używałbym go do testowania części systemu, które są problematyczne (interfejs użytkownika jest częstym przykładem, ale nie zawsze tak jest)

Największą pułapką jest to, że programiści testują zbyt dużą jednostkę lub uważają metodę za jednostkę. Jest to szczególnie ważne, jeśli nie rozumiesz Inwersji kontroli - w takim przypadku testy jednostkowe zawsze zamieniają się w kompleksowe testy integracyjne. Test jednostkowy powinien testować indywidualne zachowania - a większość metod ma wiele zachowań.

Największym nieporozumieniem jest to, że programiści nie powinni testować. Wierzą w to tylko źli lub leniwi programiści. Czy facet budujący dach nie powinien tego testować? Czy lekarz wymieniający zastawkę serca nie powinien testować nowej zastawki? Tylko programista może przetestować, czy jego kod robi to, co zamierzał (QA może testować przypadki skrajne - jak zachowuje się kod, gdy nakazuje mu robić rzeczy, których program nie zamierzał, a klient może wykonać test akceptacyjny - czy kod robi co zapłacił za to klient)

Główną różnicą w testowaniu jednostkowym, w przeciwieństwie do „otwarcia nowego projektu i przetestowania tego konkretnego kodu” jest to, że jest zautomatyzowany , a zatem powtarzalny .

Jeśli przetestujesz kod ręcznie, może Cię przekonać, że kod działa idealnie - w obecnym stanie . Ale co tydzień później, kiedy dokonałeś w nim drobnej modyfikacji? Czy chcesz ponownie przetestować go ręcznie, gdy tylko coś zmieni się w kodzie? Najprawdopodobniej nie :-(

Ale jeśli można uruchomić testy w każdej chwili, za pomocą jednego kliknięcia, dokładnie w ten sam sposób, w ciągu kilku sekund , wtedy będzie ci pokazać natychmiast, gdy coś jest zepsute. A jeśli zintegrujesz testy jednostkowe z procesem zautomatyzowanej kompilacji, będą ostrzegać cię o błędach, nawet w przypadkach, gdy pozornie całkowicie niezwiązana zmiana zepsuła coś w odległej części bazy kodu - kiedy nawet nie przyszło ci do głowy, że istnieje potrzeba ponownego przetestowania tej konkretnej funkcjonalności.

Jest to główna przewaga testów jednostkowych nad testami ręcznymi. Ale czekaj, jest więcej:

• testy jednostkowe drastycznie skracają pętlę sprzężenia zwrotnego podczas opracowywania : dzięki osobnemu działowi testowania może upłynąć kilka tygodni, zanim dowiesz się, że w kodzie jest błąd, do tego czasu zapomniałeś już o dużej części kontekstu, więc może to potrwać kilka godzin znajdź i napraw błąd; OTOH z testami jednostkowymi, cykl sprzężenia zwrotnego jest mierzony w sekundach, a proces naprawy błędu zwykle przebiega w stylu „o kurwa, zapomniałem sprawdzić tutaj ten warunek” :-)
• testy jednostkowe skutecznie dokumentują (rozumiesz) zachowanie twojego kodu
• testowanie jednostkowe zmusza do ponownej oceny wyborów projektowych, co skutkuje prostszym, czystszym projektem

Z kolei ramy do testowania jednostkowego ułatwiają pisanie i uruchamianie testów.

Nigdy nie uczono mnie testów jednostkowych na uniwersytecie i zajęło mi to trochę czasu, aby je zdobyć. Przeczytałem o tym, poszedłem „och, słusznie, zautomatyzowane testowanie, to może być fajne, jak sądzę”, a potem o tym zapomniałem.

Zajęło mi to trochę więcej czasu, zanim naprawdę zrozumiałem: Powiedzmy, że pracujesz na dużym systemie i piszesz mały moduł. Kompiluje się, poddajesz go testom, działa świetnie, przechodzisz do następnego zadania. Dziewięć miesięcy później i dwie wersje później ktoś inny wprowadza zmiany w pozornie niezwiązanej części programu i psuje moduł. Co gorsza, testują swoje zmiany, a ich kod działa, ale nie testują twojego modułu; do diabła, mogą nawet nie wiedzieć, że twój moduł istnieje .

A teraz masz problem: zepsuty kod jest w bagażniku i nikt nawet nie wie. Najlepszym rozwiązaniem jest tester wewnętrzny, który znajdzie go przed wysłaniem, ale naprawienie kodu, który jest opóźniony w grze, jest kosztowny. A jeśli żaden wewnętrzny tester go nie znajdzie ... to może stać się bardzo drogie.

Rozwiązaniem są testy jednostkowe. Złapią problemy, kiedy napiszesz kod - co jest w porządku - ale mogłeś to zrobić ręcznie. Prawdziwą korzyścią jest to, że złapią problemy dziewięć miesięcy później, kiedy pracujesz nad zupełnie innym projektem, ale letni stażysta uważa, że ​​będzie wyglądać lepiej, jeśli te parametry będą w kolejności alfabetycznej - a następnie test jednostkowy napisałeś, że droga powrotna kończy się niepowodzeniem, a ktoś rzuca rzeczy stażyście, dopóki nie zmieni z powrotem kolejności parametrów. Oto „dlaczego” testów jednostkowych. :-)

Wgryzając się w filozoficzne zalety testów jednostkowych i TDD, oto kilka z nich kluczowych obserwacji „żarówek”, które uderzyły mnie w moje pierwsze niepewne pierwsze kroki na drodze do oświecenia TDD (brak oryginalnych lub niekoniecznie wiadomości) ...

1. TDD NIE oznacza pisania dwukrotności kodu. Kod testowy jest zazwyczaj dość szybki i bezbolesny do napisania i jest kluczowym elementem procesu projektowania i ma kluczowe znaczenie.

2. TDD pomaga zrozumieć, kiedy przestać kodować! Twoje testy dadzą ci pewność, że na razie zrobiłeś wystarczająco dużo i możesz przestać poprawiać i przejść do następnej rzeczy.

3. Testy i kod współpracują ze sobą w celu uzyskania lepszego kodu. Twój kod może być zły / błędny. Twój TEST może być zły / błędny. W TDD liczysz na ZARÓWNO, że BOTH jest zły / buggy jest dość niski. Często jest to test, który wymaga naprawy, ale nadal jest to dobry wynik.

4. TDD pomaga w zaparciach kodujących. Znasz to uczucie, że masz tak wiele do zrobienia, że ​​ledwo wiesz, od czego zacząć? Jest piątek po południu, jeśli odkładasz na kilka godzin więcej ... TDD pozwala bardzo szybko zrealizować to, co uważasz za konieczne, i szybko przyspiesza kodowanie. Podobnie jak szczury laboratoryjne, myślę, że wszyscy reagujemy na to duże zielone światło i ciężko pracujemy, aby go zobaczyć!

5. W podobny sposób te typy projektantów mogą ZOBACZYĆ, nad czym pracują. Mogą odejść na przerwę na sok / papierosa / iPhone'a i wrócić do monitora, który natychmiast daje im wizualną wskazówkę, gdzie dotarli. TDD daje nam coś podobnego. Łatwiej jest zobaczyć, gdzie dotarliśmy, gdy życie interweniuje ...

6. Myślę, że to Fowler powiedział: „Niedokładne testy, często uruchamiane, są znacznie lepsze niż testy idealne, które w ogóle nie są pisane”. Interpretuję to jako udzielenie mi pozwolenia na pisanie testów, w których moim zdaniem będą one najbardziej przydatne, nawet jeśli reszta mojego kodu jest żałośnie niepełna.

7. TDD pomaga na różne zaskakujące sposoby. Dobre testy jednostkowe mogą pomóc w udokumentowaniu tego, co należy zrobić, mogą pomóc w migracji kodu z jednego projektu do drugiego i zapewnić nieuzasadnione poczucie wyższości nad kolegami nie testującymi :)

Ta prezentacja jest doskonałym wprowadzeniem do wszystkich pysznych testów dobroci.

Chciałbym polecić książkę xUnit Testing Patterns autorstwa Gerarda Meszarosa. Jest duży, ale stanowi świetne źródło informacji na temat testów jednostkowych. Oto link do jego strony internetowej, na której omawia podstawy testów jednostkowych. http://xunitpatterns.com/XUnitBasics.html

Używam testów jednostkowych, aby zaoszczędzić czas.

Podczas budowania logiki biznesowej (lub dostępu do danych) testowanie może często obejmować wpisywanie rzeczy na wielu ekranach, które mogą jeszcze nie zostać ukończone. Automatyzacja tych testów oszczędza czas.

Dla mnie testy jednostkowe są rodzajem modułowej uprzęży testowej. Zwykle jest co najmniej jeden test na funkcję publiczną. Piszę dodatkowe testy obejmujące różne zachowania.

Wszystkie specjalne przypadki, o których pomyślałeś przy opracowywaniu kodu, można zapisać w kodzie w testach jednostkowych. Testy jednostkowe stają się również źródłem przykładów użycia kodu.

O wiele szybciej jest dla mnie odkrycie, że mój nowy kod psuje coś w moich testach jednostkowych, niż sprawdzenie kodu i poproszenie jakiegoś programisty front-end o znalezienie problemu.

Do testowania dostępu do danych staram się pisać testy, które albo się nie zmieniają, albo po sobie sprzątają.

Testy jednostkowe nie będą w stanie rozwiązać wszystkich wymagań testowych. Będą mogli zaoszczędzić czas programowania i przetestować kluczowe części aplikacji.

To jest moje zdanie na ten temat. Powiedziałbym, że testowanie jednostkowe to praktyka pisania testów oprogramowania w celu sprawdzenia, czy twoje prawdziwe oprogramowanie robi to, do czego jest przeznaczone. Zaczęło się od jUnit w świecie Java i stało się najlepszą praktyką w PHP, a także w SimpleTest i phpUnit . Jest to podstawowa praktyka programowania ekstremalnego i pomaga mieć pewność, że po edycji oprogramowanie nadal działa zgodnie z przeznaczeniem. Jeśli masz wystarczającą liczbę testów, możesz dokonać poważnego refaktoryzacji, naprawy błędów lub szybko dodać funkcje, znacznie mniej obawiając się wprowadzenia innych problemów.

Jest to najbardziej skuteczne, gdy wszystkie testy jednostkowe można uruchomić automatycznie.

Testy jednostkowe są generalnie związane z rozwojem OO. Podstawową ideą jest stworzenie skryptu, który konfiguruje środowisko dla twojego kodu, a następnie ćwiczy go; piszesz asercje, określasz zamierzone dane wyjściowe, które powinieneś otrzymać, a następnie wykonujesz skrypt testowy przy użyciu frameworku takiego jak te wspomniane powyżej.

Środowisko uruchomi wszystkie testy z twoim kodem, a następnie zgłosi sukces lub niepowodzenie każdego testu. phpUnit jest domyślnie uruchamiany z wiersza poleceń Linuksa, chociaż dostępne są dla niego interfejsy HTTP. SimpleTest jest z natury oparty na Internecie i jest znacznie łatwiejszy w uruchomieniu, IMO. W połączeniu z xDebug, phpUnit oferuje automatyczne statystyki pokrycia kodu, które dla niektórych osób są bardzo przydatne.

Niektóre zespoły piszą haczyki ze swojego repozytorium subversion, aby testy jednostkowe były uruchamiane automatycznie przy każdym zatwierdzeniu zmian.

Dobrą praktyką jest utrzymywanie testów jednostkowych w tym samym repozytorium, co aplikacja.

Biblioteki takie jak NUnit , xUnit lub JUnit są po prostu obowiązkowe, jeśli chcesz rozwijać swoje projekty przy użyciu podejścia TDD spopularyzowanego przez Kenta Becka:

Możesz przeczytać Wstęp do testowania opartego na testach (TDD) lub książkę Kenta Becka Test Driven Development: przez przykład .

Następnie, jeśli chcesz mieć pewność, że Twoje testy obejmują „dobrą” część kodu, możesz użyć oprogramowania takiego jak NCover , JCover , PartCover lub cokolwiek innego. Podadzą ci procent pokrycia twojego kodu. W zależności od tego, na ile jesteś biegły w TDD, będziesz wiedział, czy ćwiczyłeś wystarczająco dobrze :)

Testowanie jednostkowe to testowanie jednostki kodu (np. Pojedynczej funkcji) bez potrzeby infrastruktury, na której opiera się ta jednostka kodu. tj. przetestuj to w izolacji.

Jeśli na przykład funkcja, którą testujesz, łączy się z bazą danych i wykonuje aktualizację, w teście jednostkowym możesz nie chcieć tej aktualizacji. Zrobiłbyś to, gdyby był to test integracyjny, ale w tym przypadku tak nie jest.

Test jednostkowy sprawiłby więc funkcjonalność zawartą w testowanej „funkcji” bez skutków ubocznych aktualizacji bazy danych.

Powiedz, że twoja funkcja pobrała pewne liczby z bazy danych, a następnie wykonała standardowe obliczenie odchylenia. Co próbujesz tutaj przetestować? Czy odchylenie standardowe jest obliczane poprawnie lub czy dane są zwracane z bazy danych?

W teście jednostkowym chcesz po prostu sprawdzić, czy odchylenie standardowe jest poprawnie obliczone. W teście integracji chcesz przetestować obliczenia odchylenia standardowego i pobieranie bazy danych.

Testowanie jednostkowe polega na pisaniu kodu, który testuje kod aplikacji.

Część Unit w nazwie dotyczy zamiaru testowania małych jednostek kodu (na przykład jednej metody) na raz.

xUnit jest w stanie pomóc w tych testach - są to frameworki, które pomagają w tym. Częścią tego są zautomatyzowane programy testujące, które informują o tym, który test się nie powiedzie, a który zda.

Mają także możliwości skonfigurowania wspólnego kodu, który jest potrzebny w każdym teście przed rozdaniem, i zburzenia go po zakończeniu wszystkich testów.

Możesz wykonać test, aby sprawdzić, czy zgłoszony został wyjątek, bez konieczności samodzielnego pisania całego bloku catch catch.

Myślę, że nie rozumiesz, że frameworki testowania jednostkowego, takie jak NUnit (i tym podobne), pomogą ci w automatyzacji testów małych i średnich. Zwykle możesz uruchomić testy w GUI (na przykład w przypadku NUnit ), po prostu klikając przycisk, a następnie - miejmy nadzieję - zobacz pasek postępu na zielono. Jeśli zmieni kolor na czerwony, środowisko pokazuje, który test się nie powiódł i co dokładnie poszło nie tak. W normalnym teście jednostkowym często używasz asercji, np. Assert.AreEqual(expectedValue, actualValue, "some description")- więc jeśli dwie wartości są nierówne, zobaczysz błąd z informacją „jakiś opis: oczekiwany <wartość oczekiwana>, ale <wartość rzeczywista>”.

Podsumowując, testowanie jednostkowe sprawi, że testowanie będzie szybsze i znacznie wygodniejsze dla programistów. Możesz uruchomić wszystkie testy jednostkowe przed zatwierdzeniem nowego kodu, aby nie przerwać procesu kompilacji innych programistów tego samego projektu.

Użyj Testivus . Wszystko, co musisz wiedzieć, jest tam :)

Testowanie jednostkowe jest praktyką, aby upewnić się, że funkcja lub moduł, który zamierzasz wdrożyć, będzie zachowywać się zgodnie z oczekiwaniami (wymagania), a także upewnić się, jak zachowuje się w scenariuszach takich jak warunki brzegowe i nieprawidłowe dane wejściowe.

xUnit , NUnit , mbUnit itp. to narzędzia, które pomagają w pisaniu testów.

Test Driven Development ma w pewnym sensie termin Test jednostkowy. Jako stary licznik wspomnę o bardziej ogólnej jego definicji.

Test jednostkowy oznacza również testowanie pojedynczego elementu w większym systemie. Ten pojedynczy komponent może być biblioteką DLL, exe, biblioteką klas itp. Może to być nawet pojedynczy system w aplikacji wielosystemowej. Ostatecznie test jednostkowy kończy się testowaniem tego, co chcesz nazwać pojedynczym elementem większego systemu.

Następnie przejdziesz do testowania zintegrowanego lub systemowego, sprawdzając, jak działają wszystkie komponenty.

Przede wszystkim, niezależnie od tego, czy mówimy o testowaniu jednostkowym, czy innych testach automatycznych (integracja, ładowanie, testowanie interfejsu użytkownika itp.), Kluczową różnicą w stosunku do tego, co sugerujesz, jest to, że jest zautomatyzowany, powtarzalny i nie wymaga żadnych zasobów ludzkich do spożycia (= nikt nie musi przeprowadzać testów, zwykle uruchamiają się po naciśnięciu jednego przycisku).

Poszedłem na prezentację na temat testów jednostkowych na FoxForward 2007 i powiedziano mi, aby nigdy nie testować jednostkowo niczego, co działałoby z danymi. W końcu, jeśli testujesz na danych na żywo, wyniki są nieprzewidywalne, a jeśli nie testujesz na danych na żywo, tak naprawdę nie testujesz napisanego kodu. Niestety, to większość kodowania, które obecnie wykonuję. :-)

Ostatnio zrobiłem zdjęcie TDD, kiedy pisałem procedurę zapisywania i przywracania ustawień. Najpierw zweryfikowałem, że mogę utworzyć obiekt pamięci. Potem miał metodę, którą musiałem wywołać. Wtedy mógłbym to nazwać. Potem mogłem przekazać parametry. Potem mogłem przekazać określone parametry. I tak dalej, aż w końcu sprawdziłem, czy to zapisze określone ustawienie, pozwoli mi je zmienić, a następnie przywrócić dla kilku różnych składni.

Nie doszedłem do końca, ponieważ potrzebowałem-rutyny-teraz-cholera, ale to było dobre ćwiczenie.

Co robisz, jeśli dostajesz kupę bzdur i wydajesz się, że utknąłeś w ciągłym stanie czyszczenia, który wiesz, że po dodaniu jakiejkolwiek nowej funkcji lub kodu może uszkodzić bieżący zestaw, ponieważ obecne oprogramowanie jest jak dom karty?

Jak zatem możemy przeprowadzić testy jednostkowe?

Zaczynasz mały. Projekt, w który właśnie się zaangażowałem, nie miał testów jednostkowych jeszcze kilka miesięcy temu. Gdy zasięg był tak niski, po prostu wybieraliśmy plik, który nie był objęty, i klikaliśmy „dodaj testy”.

Obecnie mamy ponad 40% i udało nam się zebrać większość nisko wiszących owoców.

(Najlepsze jest to, że nawet przy tak niskim poziomie pokrycia natrafiliśmy już na wiele przypadków, w których kod robi coś złego, a testy go wychwyciły. To ogromny motywator, aby zachęcić ludzi do dodania kolejnych testów.)

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.

Testy jednostkowe i TDD ogólnie umożliwiają krótsze cykle sprzężenia zwrotnego na temat tworzonego oprogramowania. Zamiast dużej fazy testowej na samym końcu implementacji, stopniowo testujesz wszystko, co piszesz. To bardzo podnosi jakość kodu, jak od razu widać, gdzie możesz mieć błędy.