Czy korzystasz z testów jednostkowych w pracy? Jakie korzyści z nich czerpiesz? [Zamknięte]

18

Planowałem przestudiować i zastosować testy jednostkowe w moim kodzie, ale po rozmowie z kolegami niektórzy z nich zasugerowali mi, że nie jest to konieczne i ma bardzo niewielkie zalety. Twierdzą również, że tylko kilka firm faktycznie przeprowadza testy jednostkowe z oprogramowaniem produkcyjnym.

Jestem ciekawy, w jaki sposób ludzie zastosowali testy jednostkowe w pracy i jakie korzyści czerpią z ich używania, np. Lepsza jakość kodu, skrócony czas programowania w dłuższej perspektywie itp.

Anonimowy
źródło
13
„Twierdzą również, że tylko nieliczne firmy przeprowadzają testy jednostkowe z oprogramowaniem produkcyjnym”. Oznacza to, że tylko kilka firm produkuje oprogramowanie wysokiej jakości. Z którą grupą chcesz się przyłączyć? Jak „tylko kilka firm” może być negatywnym stwierdzeniem? Tylko nieliczne firmy są niezwykle dochodowe; czy to źle? Tylko kilka firm to naprawdę wspaniałe miejsca pracy; czy to źle? Tylko kilka firm minimalizuje wytwarzanie odpadów; czy to źle? Ich komentarz „tylko kilka firm” jest bezsensowny.
S.Lott
2
jest też prawdopodobnie niepoprawny, anegdotyczny, jeszcze nie pracowałem dla firmy, która przynajmniej nie przeprowadziła testów jednostkowych na pewnym poziomie
jk.
1
Sądzę, że programista, który uważa, że ​​testy jednostkowe „mają bardzo małą korzyść”, jest niedoświadczony lub po prostu nie wie, jak pisać skuteczne testy jednostkowe.
Toby
Ile testów jednostkowych używają programiści tej witryny?
JeffO
1
@ S.Lott: bez sensu tak, ale wciąż jest używany jako argument, aby nie przeprowadzać testów jednostkowych przez tych, którzy nie chcą tego robić. Nie bronię tutaj ich punktu widzenia, wręcz przeciwnie. Jednak to stwierdzenie jest nadal przedstawiane, a ci, którzy je tworzą, są przekonani o jego wartości, a ponieważ to oni, musimy przekonać o rzeczywistych korzyściach z testowania go, ponieważ bezsensowność nie pomoże znacznie większej przyczyny.
Newtopian

Odpowiedzi:

20

niektóre sugerują, że nie jest to konieczne

Cóż, w ścisłym tego słowa znaczeniu mają rację: testowanie, przeglądy kodu, kontrola źródła itp. Również nie są absolutnie konieczne . Tyle, że bardzo niewielu rozsądnych programistów pracuje bez nich w dłuższej perspektywie. Większość z nas nauczyła się (często na własnej skórze, na podstawie własnych błędów), dlaczego są to najlepsze praktyki.

i ma bardzo małą zaletę.

W większości przypadków nie jest to prawdą. To znaczy, jeśli mówimy o oprogramowaniu produkcyjnym, które ma być używane - a więc i do konserwacji - przez wiele lat.

Twierdzą również, że tylko nieliczne firmy przeprowadzają testy jednostkowe z oprogramowaniem produkcyjnym.

To może być prawda (choć z mojego doświadczenia coraz mniej), ale nie ma nic do powiedzenia na temat wartości testów jednostkowych. W przeciwieństwie do tego stary żart „Gówno jest dobre - 50 miliardów much nie może się mylić!” ;-)

czy stosowałeś w swojej pracy test jednostkowy i co z niego otrzymujesz? (np. lepsza jakość kodu, skrócenie czasu w dłuższej perspektywie itp.)

W swojej pracy stosuję testy jednostkowe, o ile to możliwe, od ponad 10 lat. To poczucie zaufania do mojego kodu, wiedząc, że działa - i mogę to udowodnić w dowolnym miejscu, w ciągu kilku sekund, w kółko, zamiast po prostu w to wierzyć - jest bezcenne. Daje mi to odwagę do zmiany kodu, ulepszenia jego projektu lub naprawy błędów, bez obawy o uszkodzenie istniejącej funkcjonalności. Nigdy nie wrócę do dawnych czasów „kodowania i modlitwy”.

Péter Török
źródło
14

Robię nieprzyzwoite, ale nie (lub nieliczne) w pracy

Główne zalety testowania, które otrzymuję, to fakt, że refaktoryzacja jest o wiele łatwiejsza i że regresja (tj. Przywrócenie już naprawionych błędów) jest zauważalna.

Testowanie życia za pomocą „kompilacji”: sprawdzasz oprogramowanie z uruchomionymi testami i nie rejestrujesz się, dopóki wszystkie testy nie zostaną uruchomione z twoją modyfikacją.

Z mojego doświadczenia wynika, że ​​pisanie testów jest prawie bezużyteczne, gdy wykonuje się je w stylu samotnego wilka. Kiedy zawsze musisz naprawić testy, aby uwzględnić zmiany wprowadzone przez innych, kiedy testy mogą zostać usunięte przez twoich współpracowników (zdarzają się w moich poprzednich zadaniach), ponieważ „nie pozwolą mi się wdrożyć” itp., To tylko dodatkowa praca z korzyści natychmiast spalone przez resztę zespołu.

Kiedy cały zespół się zgadza (a w zespole 1 to jest łatwe), z mojego doświadczenia wynika, że ​​testy są dużą korzyścią dla jakości, stylu i solidności Projektu.

Ale w zespole, który szczerze wierzy, że „tylko kilka firm automatycznie testuje swój kod” i jest przekonany, że i tak to strata czasu, wydaje się, że nie ma nadziei na uzyskanie korzyści, ale jest duża szansa, że ​​zostaniesz stworzony odpowiedzialny za „stratę czasu” przy wskazywaniu błędów.

Najlepszą szansą na wprowadzenie testów byłby mały projekt na twoją wyłączną odpowiedzialność. Tam miałbyś okazję zabłysnąć i wykazać wartość testów.

keppla
źródło
1
Przepraszam, że zabrzmiało to negatywnie, ale wciąż mnie palą „jak załatwić sprawę jak chrząknięcie”;)
keppla
Bardzo dobra rada. Problem polega na tym, że przy prawidłowym wykonaniu nie widać korzyści z testowania jednostkowego. Potencjalnie widzisz szkodę tylko, gdy nie wykonujesz testów jednostkowych. Więc jeśli chcesz przekonać innych statystykami, a nie teorią, to nieźle sobie radzisz.
Peter Kruithof
12
@ keppla, piszę testy jednostkowe w projektach, w których moi koledzy z zespołu nawet nie słyszeli o testach jednostkowych. Gdy moje testy zdołały wyłapać kilka błędów, które w przeciwnym razie prześlizgnęłyby się niezauważone, inne zaczęły to zauważać i wkrótce chciały się nauczyć samodzielnego testowania jednostek. Konkretny dowód jest królem.
Péter Török
1
@ keppla, dość uczciwie, jeśli członkowie drużyny są stronniczy do poziomu utraty zdrowego rozsądku, nie ma sposobu, aby przekonać ich logicznym dowodem :-( W takim przypadku, przy silnym wsparciu zarządzania, możesz nadal udać się przeforsować pomysł , ale bez tego nie ma nadziei
Péter Török
3
Często „przełamujesz” testy, zmieniając interfejs, usuwając klasy itp. Kiedy wykonujesz „testuj pierwszy”, nie postrzegasz tego jako „łamanie”, ale jako pierwszy krok „czerwony”. Ale kiedy jesteś w trybie „Po prostu dodaj kilka linii, aż to zadziała”, testy to tylko więcej linii. A kiedy „naprawione” przez kogoś takiego, testy pogarszają się pod względem przydatności, dopóki nie przyniosą żadnego celu. Selffulfilling proroctwo 4tw!
keppla
7

Staram się popierać twoich kolegów, ale tylko do pewnego stopnia.

Problem z testami jednostkowymi polega na tym, że są one często i bezmyślnie pisane na trywialnych przypadkach, w których pobieżne badanie kodu ujawnia, że ​​zadziała ono bez względu na wszystko. Na przykład:

def add(x, y)
  x + y
end

Wraz z tuzinem testów, aby upewnić się, że dodatek rzeczywiście będzie działał dla dowolnie wybranych przypadków użycia. Duh ...

Ogólna zasada testowania jednostkowego jest taka: jeśli twój kod nie zawiera błędów, to dlatego, że nie przetestowałeś wystarczająco dużo. Teraz, kiedy napisać odpowiednie testy jednostkowe. Odpowiedzi:

  1. Kiedy testujesz
  2. Kiedy debugujesz
  3. Gdy rozwijasz naprawdę trudne rzeczy

Przejrzyjmy każdy z nich, przypuśćmy, że tworzysz jakąś aplikację internetową.

Piszesz kod do nowej funkcjonalności, która powinna już działać całkiem dobrze. Następnie sięgasz po przeglądarkę i sprawdzasz, czy działa, testując ją bardziej intensywnie, prawda? Bzzzt! ... Błędna odpowiedź. Piszesz test jednostkowy. Jeśli nie zrobisz tego teraz, prawdopodobnie nigdy tego nie zrobisz. Jest to jedno z miejsc, w których testy jednostkowe działają bardzo dobrze: testowanie funkcjonalności na wysokim poziomie.

Następnie odkrywasz błąd (kto nigdy go nie omija?). To prowadzi nas do punktu drugiego. Zanurz się w kodzie i zacznij postępować zgodnie z instrukcjami. W tym czasie napisz testy jednostkowe w kluczowych punktach przerwania, w których kluczowe są spójne i poprawne dane.

Ostatni punkt jest odwrotny. Projektujesz kosmatą funkcjonalność, która wymaga mnóstwa metaprogramowania. Szybko tworzy drzewo decyzyjne z tysiącami potencjalnych scenariuszy i musisz upewnić się, że każdy z nich działa. Pisząc takie rzeczy, prosta zmiana tutaj lub tam może mieć niewyobrażalne konsekwencje w dalszej części łańcucha pokarmowego. Załóżmy, że projektujesz implementację MPTT przy użyciu wyzwalaczy SQL - tak, aby mogła ona współpracować z instrukcjami wieloliniowymi.

W tego rodzaju kolczastym środowisku zazwyczaj chcesz zautomatyzować swoje testy. Więc piszesz skrypty do automatyzacji generowania danych testowych i uruchamiasz ładunek testów jednostkowych na tych danych testowych. Jedną z kluczowych rzeczy, aby nie zgubić się przy tym, jest to, że musisz także napisać testy jednostkowe dla generatora testów jednostkowych.

Konkluzja: testy jednostkowe, zdecydowanie tak. Ale oszczędzaj sobie podstawowych funkcji - dopóki nie będziesz ich potrzebować do debugowania lub upewnienia się, że niektóre włochate funkcje działają poprawnie (w tym, w tym drugim przypadku, same testy).

Denis de Bernardy
źródło
Jak ujął to Kent Beck: „przetestuj wszystko, co może się zepsuć”.
Péter Török
1
Zgadzam się z nim całym sercem. Mam przede wszystkim nadzieję, że PO weźmie pod uwagę: nie zapomnij przetestować testów, jeśli dotyczy. :-)
Denis de Bernardy
7

Cały kod musi zostać przetestowany. Nie ma wyboru.

Nieprzetestowany kod jest bezużyteczny: nic nie można powierzyć.

Możesz pisać testy jednostkowe lub możesz napisać testy integracji wyższego poziomu lub testy akceptacyjne.

Testy jednostkowe są łatwiejsze do napisania, łatwiejsze do debugowania i łatwiejsze do zarządzania.

Testy integracyjne opierają się na założeniach, że jednostki faktycznie działają. Bez testów jednostkowych, skąd wiesz, że jednostki działają? Jak możesz debugować test integracji, jeśli nie wiesz, że poszczególne zintegrowane jednostki faktycznie działają?

Testy odbiorcze, podobnie, zależą od wszystkich pracujących elementów i części. Skąd możesz wiedzieć, że części i części działają bez posiadania zestawu testów jednostkowych?

Testowanie jest obowiązkowe. Wszystkie testy wyższego poziomu zależą od faktycznie działających jednostek.

To sprawia, że ​​testowanie urządzeń jest logiczną koniecznością. Nie ma innego wyboru.

S.Lott
źródło
1
Nie ma innego wyboru ... jeśli zależy Ci na jakości. Większość organizacji zajmujących się oprogramowaniem nie dba o jakość (o ile odmawia wysyłania oprogramowania, o którym wiadomo, że jest zepsute).
Joeri Sebrechts
@Jeri Sebrechts: To nie jest problem z jakością. Jest to kwestia „gotowe”. Nawet złe oprogramowanie musi zostać przetestowane, aby udowodnić, że coś robi - cokolwiek. Prosta logika podpowiada, że ​​musi istnieć test, aby udowodnić, że działa. Nawet zły test to test. Prosta logika podpowiada, że ​​test całości musi obejmować testy części. Testowanie jednostkowe jest po prostu wymagane przez logikę, nic więcej. Nie względy jakościowe, ale z definicji „zrobione”.
S.Lott,
1
Korzystanie z oprogramowania to test sam w sobie. Wiele organizacji chętnie sprawi, że użytkownik przeprowadzi testy. Nie twierdzę, że to dobrze, ale tak już jest. Możesz zrezygnować z testowania przed dostawą, odciążając testy użytkownika końcowego. Możesz, ale nie powinieneś.
Joeri Sebrechts
1
@Jeri Sebrechts: Właściwie nie możesz. Nie można przekazać oprogramowania - losowo - użytkownikowi w celu przetestowania akceptacji. Musisz uruchomić oprogramowanie przynajmniej raz, aby mieć pewność, że działa. To jest test - zły test - ale test. Logicznie, ten zły test obejmował złe testy jednostkowe. Istnieli, chociaż byli bardzo źli.
S.Lott,
twoja definicja testu jednostkowego jest bezużyteczna w tej dyskusji. Test jednostkowy jest testem skodyfikowanym i wcale nie jest konieczny do wysyłki oprogramowania. (ale dobrze jest zrobić w wielu okolicznościach)
Martin Ba
6

Używam testów jednostkowych do wszystkiego, co piszę, i nie pozwalam, aby testowany kod przejrzał bez przypadku testowego. (Ale brakuje mi narzędzia pokrycia, więc muszę rozumować o pokryciu testowym. Jedna rzecz na raz ...)

To dość proste: jeśli nie możesz wykazać, że Twój kod działa (a jaki jest lepszy sposób niż specyfikacja wykonywalna w postaci testu?), To nie działa .

To daje mi:

  • Spokój: mój serwer CI mówi mi, że cała moja baza kodów działa.
  • Zdolność do ulepszenia mojego kodu: mogę zrestrukturyzować swój kod - przebudować go - wiedząc, że po restrukturyzacji nic nie zepsułem.
Frank Shearar
źródło
2
Dodam do tego jedno bardzo ważne zastrzeżenie - samo testowanie jednostkowe nie zagwarantuje, że „cała baza kodu działa”. Zapewni to, że wszystkie jednostki kodu będą działały w izolacji, ale nadal istnieje ogromna możliwość wystąpienia błędów integracji, błędów w wizualnej prezentacji danych itp.
Ryan Brunner
Chyba że twoje środowisko „mija”, jeśli nie możesz wykazać, że twój kod nie działa, to działa ”. : p
Davy8
@Ryan: Oczywiście twoje testy integracyjne powinny prowadzić cały projekt. Pytanie dotyczyło testów jednostkowych, więc mówiłem o testach jednostkowych, ale oczywiście powinieneś zademonstrować potrzebę fragmentu kodu, przechodząc nieudany test integracyjny. I oczywiście powinieneś mieć serwer CI automatycznie wdrażający bazę kodu i uruchamiający wszystkie testy
Frank
@ Davy8: W którym przypadku masz poważniejsze problemy, które „czy testy jednostkowe działają?”.
Frank Shearar
4

Testowanie jednostkowe jest dyscypliną. Ponieważ kod nie jest konieczny do działania, często jest odrzucany.

Jest to jednak sprawdzona metoda, która prowadzi do solidnego i mniej błędnego kodu. Nie sądzę, żebym musiał ci wyjaśnić korzyści, o których już wspomniałeś. Jeśli przyjrzysz się niektórym wiodącym projektom typu open source, bez względu na to, czy są to biblioteki javascript, frameworki z pełnym stosem, czy aplikacje jednofunkcyjne, wszystkie używają testów jednostkowych.

Podejrzewam, że twoi koledzy, którzy nie zalecają korzystania z niego, nie są programistami. Jeśli tak, powiedzmy, że nie ma wielu ludzi, których cenię wyżej niż takich jak Martin Fowler czy Kent Beck ;).

Podobnie jak większość najlepszych praktyk, korzyści są długoterminowe, musisz poświęcić na to trochę czasu. Możesz napisać długi skrypt kodu proceduralnego, ale wszyscy wiemy, że chciałbyś napisać go w stylu obiektowym, kiedy trzeba go przeredagować po 2 latach.

To samo dotyczy testów jednostkowych. Jeśli piszesz testy jednostkowe dla krytycznych części w swojej aplikacji, możesz być pewien, że działa przez cały czas zgodnie z przeznaczeniem, nawet po refaktoryzacji kodu. Może kodujesz tak dobrze, że nigdy nie masz błędu regresji. Ale jeśli tego nie zrobisz lub do zespołu dołączy nowy programista, musisz się upewnić, że błędy z przeszłości się nie powtórzą. Myślę, że twój szef też byłby z tego zadowolony, w przeciwieństwie do konieczności zgłaszania błędów, które jego zdaniem zostały rozwiązane pół roku temu.

Peter Kruithof
źródło
3

Testy jednostkowe wymagają języka przyjaznego dla testów jednostkowych, projektu przyjaznego dla testów jednostkowych i problemu przyjaznego dla testów jednostkowych.

C ++, projektowanie wielowątkowe i GUI będą koszmarem, a problem będzie przerażający.

.NET, jednowątkowy zestaw dll wielokrotnego użytku, czysta logika obliczeniowa to pestka.

Czy warto, nie mogę tak naprawdę powiedzieć.

Czy dużo refaktoryzujesz? Czy widzisz w swoim kodzie „głupie robaki”, takie jak „off by one”?

Cokolwiek robisz, nie bądź tym facetem, który krytykuje innych, mówiąc, że „nie masz testów jednostkowych, więc ssiesz”. Jeśli testy ci pomogą, skorzystaj z niej, jeśli nie, to nie jest tak, że są srebrną kulą.

Koder
źródło
1
Dlaczego projektowanie wielowątkowe byłoby koszmarem? Zaprojektuj punkty synchronizacji i przetestuj je.
Frank Shearar
1
Ponieważ czas zależy od faz księżyca, zegara procesora, śmieci i praktycznie wszystkiego. Przy jednym zameldowaniu test może się nie powieść, jeśli masz szczęście, na 1000 innych nie.
Koder
1
Napisałem testy wielowątkowe. Jest to zdecydowanie wykonalne.
Frank Shearar
4
śmieci, możesz przeprowadzić test jednostkowy w dowolnym języku.
jk.
1
Trudno jest pisać testy jednostkowe dla interakcji GUI, ale dlatego wyizolowaliśmy cokolwiek (nasz kod silnika), co nie ma związku z GUI. Pomógł nam podjąć dobrą decyzję o oddzieleniu silnika od GUI, a testy jednostkowe działają jak nasz interfejs zamiast GUI, pytając i dostarczając informacji, których normalnie potrzebowalibyśmy.
Szansa
3

Ja chcę , ale miałem nieszczęście prawie całkowicie pracy w firmach, które po prostu nie dbają o jakość i są bardziej skoncentrowane z wyrzuceniem śmieci siebie, że może trochę Sorta-if-you-zez prac. Wspomniałem o testach jednostkowych i dostaję „Huh?” rodzaj wyglądu (ten sam wygląd, który otrzymuję, gdy wspominam o zasadach SOLID lub ORM, lub projektuję wzorce poza „klasą ze wszystkimi metodami statycznymi” lub zgodnie z konwencjami nazewnictwa .NET). Byłem tylko w jednej firmie, która to rozumiała, i niestety była to umowa krótkoterminowa, a dział został przycięty, aby obniżyć koszty, więc nie było wystarczająco dużo czasu na naukę.

Zajmowałem się testami jednostkowymi w wyrzucanych manekinach, ale tak naprawdę nie miałem pojęcia o pełnych możliwościach TDD / BDD, a brak mentora, który byłby w stanie pomóc, znacznie utrudnia prawidłowe działanie.

Wayne Molina
źródło
2

Używamy ich. Jedną wielką korzyścią, jaką otrzymujemy, jest sprawdzanie przez system testów jednostkowych wycieków pamięci i błędów alokacji . Czasami problem tkwi w samym kodzie testu jednostkowego, ale często w kodzie produkcyjnym.

To świetny sposób na znalezienie tych rzeczy, których brakuje w przeglądzie kodu.

Testy jednostkowe (powinny) również przebiegać bardzo szybko i mogą być wykonywane w ramach ciągłej integracji po każdym zatwierdzeniu, a także przez programistów przed zatwierdzeniem. Mamy ponad 1000, których uruchomienie zajmuje mniej niż 20 sekund.

Porównaj z ponad 40 minutami dla testów automatyzacji na poziomie systemu i godzinami / dniami dla testów ręcznych. Oczywiście testy jednostkowe nie są jedynymi testami, które powinieneś robić, ale na szczegółowym poziomie kodu mogą pomóc znaleźć błędy i przetestować te przypadki brzegowe, których testy systemu / integracji nie mogą dotknąć. Nasz kod musi zostać przetestowany z ponad 75% pokryciem decyzji i 100% pokryciem funkcji, co byłoby bardzo trudne do osiągnięcia bez testów jednostkowych.

Hugo
źródło
2

Powiedziałbym, że testy jednostkowe wnoszą wartość dodaną, ale nie jestem wielkim uczniem TDD. Największą korzyść czerpię z testów jednostkowych, kiedy wykonuję silniki obliczeniowe lub jakikolwiek inny silnik, a następnie klasy użytkowe, testy jednostkowe są wtedy bardzo pomocne.

Wolę automatyczne testy integracji dla bloków bardziej zależnych od danych, ale wszystko zależy, jestem w branży danych, więc wiele błędów jest bardziej związanych z danymi w naszym środowisku niż cokolwiek innego, i dlatego automatyczne testy integracji działają dobrze. Sprawdzanie danych przed i po oraz generowanie raportów wyjątków z tych testów.

Testy jednostkowe naprawdę zwiększają wartość, zwłaszcza jeśli testowana jednostka może być wyposażona we wszystkie potrzebne dane wejściowe i działać samodzielnie z danym wejściem. Ponownie w moim przypadku silniki obliczeniowe i klasy użytkowe są tego doskonałym przykładem.

Marthinus
źródło
2

Koszty: Wolniej koduje, Krzywa uczenia się, Bezwładność programisty

Korzyści: Generalnie przy pierwszym testowaniu pisałem lepszy kod - SOLID mądry ...

Ale IMHO, jak sądzę, największą korzyścią jest niezawodność w większych systemach, które często się zmieniają. Dobre testy jednostkowe pozwolą zaoszczędzić twój tyłek (wydobyły), gdy wydasz wiele wersji i mogą wyeliminować dużą część kosztów związanych z ręcznymi procesami kontroli jakości. Oczywiście nie gwarantuje kodu wolnego od błędów, ale przechwytuje niektóre trudne do przewidzenia. W dużych złożonych systemach może to być naprawdę bardzo duża korzyść.

Bob_Mac
źródło
0

Kiedy mam okazję, przeprowadzam test jednostkowy w pracy i staram się przekonać moich kolegów, by zrobili to samo.

Nie jestem o tym przekonany, ale doświadczenie pokazuje, że metody użytkowe i biznesowe, które były testami jednostkowymi, są bardzo solidne i mają tendencję do wykazywania niewielkiej liczby błędów lub ich braku podczas fazy testowania, co ostatecznie zmniejsza koszty projektu.

Philippe
źródło
0

Tam, gdzie widziałem prawdziwą zaletę kodowania testów jednostkowych i włączania wykonywania testów jednostkowych do codziennego procesu budowania, był projekt z ponad 30 programistami pracującymi na 3 różnych kontynentach. Testy jednostkowe naprawdę zabłysły, gdy ktoś subtelnie zmienił klasę, którą utrzymywał, nie rozumiejąc, w jaki sposób ludzie korzystają z tej klasy. Zamiast czekać, aż kod trafi do grupy testowej, natychmiast otrzymano informację zwrotną, gdy testy jednostek innych osób zaczęły się nie udać w wyniku zmiany. [Dlatego wszystkie testy jednostkowe muszą być rutynowo uruchamiane, a nie tylko te, które napisałeś dla swojego kodu.]

Moje wytyczne dotyczące testowania jednostkowego to:

  1. Przetestuj każdy warunek, jaki możesz wymyślić dla swojego kodu, w tym nieprawidłowe dane wejściowe, granice itp.
  2. Wszystkie testy jednostkowe dla wszystkich modułów powinny być wykonywane regularnie (tj. Jako część nocnych wersji)
  3. Sprawdź wyniki testu jednostkowego!
  4. Jeśli ktoś znajdzie błąd w kodzie, który przeszedł testy, napisz dla niego nowy test!
jwernerny
źródło
0

Niedawno nauczyłem się TDD i stwierdziłem, że jest to bardzo przydatne. Daje to większą pewność, że mój kod działa zgodnie z oczekiwaniami. Wraz z ułatwieniem każdego faktoringu, który chciałbym zrobić. Za każdym razem, gdy zostanie znaleziony błąd, możesz upewnić się, że dzięki testom nie pojawi się on ponownie.

Najtrudniejsze jest pisanie dobrych testów jednostkowych.

Jest to dobry punkt odniesienia dla twojego kodu.

Schleis
źródło