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

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.

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”.

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.

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).

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.

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.

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.

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ą.

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.

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.

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.

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ść.

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.

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!

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.