Czy warto przeprowadzać testy jednostkowe? [Zamknięte]

Pracuję nad zintegrowaniem testów jednostkowych z procesem programistycznym w zespole, nad którym pracuję, i są sceptycy. Jakie są dobre sposoby przekonania sceptycznych programistów do zespołu o wartości testów jednostkowych? W moim konkretnym przypadku dodawalibyśmy testy jednostkowe, dodając funkcjonalność lub naprawiając błędy. Niestety nasza baza kodu nie nadaje się do łatwego testowania.

Każdego dnia w naszym biurze odbywa się wymiana, która przebiega mniej więcej tak:

„Człowieku, po prostu uwielbiam testy jednostkowe, właśnie mogłem wprowadzić wiele zmian w sposobie, w jaki coś działa, a następnie byłem w stanie potwierdzić, że niczego nie zepsułem, ponownie przeprowadzając test…”

Szczegóły zmieniają się codziennie, ale sentyment nie. Testy jednostkowe i rozwój oparty na testach (TDD) mają tak wiele ukrytych i osobistych korzyści, jak i oczywiste, których tak naprawdę nie można komuś wyjaśnić, dopóki sami tego nie zrobią.

Ale ignorując to, oto moja próba!

1. Testy jednostkowe pozwalają szybko wprowadzać duże zmiany w kodzie. Wiesz, że to działa teraz, ponieważ przeprowadziłeś testy, kiedy wprowadzasz zmiany, które musisz wprowadzić, musisz ponownie uruchomić testy. To oszczędza godziny.

2. TDD pomaga zrozumieć, kiedy przestać kodować. Twoje testy dają ci pewność, że na razie masz dość 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 / buggy. W TDD polegasz na szansach, że zarówno będziesz zły / buggy, że będziesz niski. Często jest to test, który wymaga naprawy, ale nadal jest to dobry wynik.

4. TDD pomaga w zaparciach kodujących. W obliczu dużego i zniechęcającego zadania, pisanie testów sprawi, że będziesz się szybko poruszać.

5. Testy jednostkowe pomagają naprawdę zrozumieć projekt kodu, nad którym pracujesz. Zamiast pisać kod, aby coś zrobić, zaczynasz od nakreślenia wszystkich warunków, którym poddajesz kod i tego, czego możesz się po nim spodziewać.

6. Testy jednostkowe zapewniają natychmiastową informację zwrotną, wszyscy lubimy wrażenie tych wszystkich zielonych świateł, kiedy to zrobimy. To bardzo satysfakcjonujące. Znacznie łatwiej jest też wybrać miejsce, w którym przerwałeś po przerwie, ponieważ możesz zobaczyć, dokąd się udałeś - to kolejne czerwone światło, które wymaga naprawy.

7. W przeciwieństwie do popularnych testów jednostkowych przekonanie nie oznacza pisania dwa razy więcej kodu lub pisania wolniej. Jest szybszy i bardziej niezawodny niż kodowanie bez testów, gdy już się zorientujesz. Sam kod testowy jest zwykle stosunkowo trywialny i nie dodaje dużego obciążenia do tego, co robisz. To jest to, w co uwierzysz tylko wtedy, gdy to robisz :)

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

9. Dobre testy jednostkowe mogą pomóc w udokumentowaniu i zdefiniowaniu, co należy zrobić

10. Testy jednostkowe pomagają w ponownym użyciu kodu. Przeprowadź migrację zarówno kodu, jak i testów do nowego projektu. Ulepszaj kod, aż testy zaczną się ponownie.

Dużo pracy, z którą jestem zaangażowany, nie sprawdza się dobrze w testach jednostkowych (interakcje użytkowników aplikacji internetowych itp.), Ale mimo to wszyscy jesteśmy zainfekowani testami w tym sklepie, a najszczęśliwsze, gdy mamy już ograniczone testy. Nie mogę wystarczająco polecić tego podejścia.

Testowanie jednostkowe przypomina chodzenie na siłownię. Wiesz, że to jest dla ciebie dobre, wszystkie argumenty mają sens, więc zaczynasz ćwiczyć. Początkowo pęd, co jest świetne, ale po kilku dniach zaczynasz się zastanawiać, czy warto. Pracujesz godzinę dziennie, aby przebrać się i biegać na kole chomika i nie jesteś pewien, czy naprawdę zyskujesz coś innego niż obolałe nogi i ramiona.

Potem, może po jednym lub dwóch tygodniach, gdy ból ustępuje, zaczyna się zbliżać Wielki Termin. Musisz spędzać każdą godzinę na przebudzeniu, próbując wykonać „użyteczną” pracę, więc wycinasz zbędne rzeczy, takie jak chodzenie na siłownię. Odpadasz z przyzwyczajenia, a zanim skończy się Big Deadline, wrócisz do punktu wyjścia. Jeśli w ogóle uda ci się wrócić na siłownię, poczujesz się tak samo obolały, jak wtedy, gdy pierwszy raz poszedłeś.

Czytasz trochę, aby sprawdzić, czy robisz coś źle. Zaczynasz odczuwać trochę irracjonalnej złośliwości wobec wszystkich sprawnych, szczęśliwych ludzi wychwalających zalety ćwiczeń. Zdajesz sobie sprawę, że nie masz wiele wspólnego. Nie muszą jechać 15 minut przed wyjściem na siłownię; jest jeden w ich budynku. Nie muszą się z nikim kłócić o korzyści płynące z ćwiczeń; jest to po prostu coś, co wszyscy robią i akceptują jako ważne. Kiedy zbliża się Wielki Termin, nie mówi się im, że ćwiczenia są niepotrzebne bardziej niż szef poprosiłby cię o zaprzestanie jedzenia.

Tak więc, aby odpowiedzieć na twoje pytanie, Testowanie Jednostkowe jest zwykle warte wysiłku, ale wymagany wysiłek nie będzie taki sam dla wszystkich. Testowanie jednostkowe może wymagać ogromnego wysiłku, jeśli masz do czynienia z bazą kodu spaghetti w firmie, która tak naprawdę nie ceni jakości kodu. (Wielu menedżerów zaśpiewa pochwały z Testów Jednostkowych, ale to nie znaczy, że będą trzymać się tego, gdy będzie to ważne).

Jeśli próbujesz wprowadzić Testowanie Jednostkowe w swojej pracy i nie widzisz wszystkich promieni słonecznych i tęcz, których oczekujesz, nie obwiniaj się. Może być konieczne znalezienie nowej pracy, aby naprawdę sprawdziło się testowanie jednostkowe.

Najlepszy sposób, aby przekonać ... znaleźć błąd, napisać test jednostkowy, naprawić błąd.

Ten konkretny błąd prawdopodobnie nigdy się nie pojawi i możesz to udowodnić za pomocą testu.

Jeśli zrobisz to wystarczająco, inni szybko to zrozumieją.

thetalkingwalnut pyta:

Jakie są dobre sposoby przekonania sceptycznych programistów do zespołu o wartości testów jednostkowych?

Każdy z nas będzie miał wiele powodów, dla których testowanie jednostkowe jest dobre. Uważam jednak, że często najlepszym sposobem przekonania kogoś do czegoś jest wysłuchanie jego argumentacji i zajęcie się nim punkt po punkcie. Jeśli słuchasz i pomagasz im wyrazić swoje obawy, możesz zająć się każdym z nich i być może przekonwertować je na swój punkt widzenia (a przynajmniej zostawić je bez nogi). Kto wie? Być może przekonają cię, dlaczego testy jednostkowe nie są odpowiednie dla twojej sytuacji. Mało prawdopodobne, ale możliwe. Być może, jeśli opublikujesz ich argumenty przeciwko testom jednostkowym, pomożemy zidentyfikować kontrargumenty.

Ważne jest, aby wysłuchać i zrozumieć obie strony argumentu. Jeśli spróbujesz zbyt gorliwie przeprowadzać testy jednostkowe bez względu na obawy ludzi, zakończysz wojnę religijną (i prawdopodobnie naprawdę bezwartościowe testy jednostkowe). Jeśli zastosujesz go powoli i zaczniesz od zastosowania go tam, gdzie zobaczysz najwięcej korzyści przy najniższych kosztach, możesz być w stanie wykazać wartość testów jednostkowych i mieć większą szansę przekonania ludzi. Zdaję sobie sprawę, że to nie jest tak proste, jak się wydaje - zwykle wymaga trochę czasu i dokładnych wskaźników, aby stworzyć przekonujący argument.

Testy jednostkowe są narzędziem, jak każde inne, i powinny być stosowane w taki sposób, aby korzyści (wyłapywanie błędów) przewyższały koszty (wysiłek związany z ich pisaniem). Nie używaj ich, jeśli nie mają sensu i pamiętaj, że są one tylko częścią Twojego arsenału narzędzi (np. Inspekcje, stwierdzenia, analizatory kodu, metody formalne itp.). Mówię moim programistom:

1. Mogą pominąć pisanie testu dla metody, jeśli mają dobry argument, dlaczego nie jest to konieczne (np. Zbyt proste, aby było tego warte lub zbyt trudne, aby było tego warte) oraz w jaki sposób metoda zostanie zweryfikowana w inny sposób (np. Kontrola, stwierdzenia , metody formalne, testy interaktywne / integracyjne). Muszą wziąć pod uwagę, że niektóre weryfikacje, takie jak kontrole i formalne dowody, są przeprowadzane w danym momencie, a następnie muszą być powtarzane za każdym razem, gdy zmienia się kod produkcyjny, podczas gdy testy jednostkowe i stwierdzenia mogą być użyte jako testy regresji (napisane raz, a następnie wykonywane wielokrotnie ). Czasami się z nimi zgadzam, ale częściej będę debatować, czy metoda jest naprawdę zbyt prosta czy zbyt trudna do przetestowania jednostkowego.

   • Jeśli deweloper twierdzi, że metoda wydaje się zbyt prosta, by upaść, czy nie warto poświęcić 60 sekund na napisanie prostego testu z 5 liniami? Te 5 wierszy kodu będzie się uruchamiać każdej nocy (robisz nocne kompilacje, prawda?) Przez następny rok lub dłużej i będzie wart wysiłku, nawet jeśli tylko raz zdarzy się złapać problem, który mógł zająć 15 minut lub dłużej i debuguj. Poza tym napisanie łatwych testów jednostkowych zwiększa liczbę testów jednostkowych, dzięki czemu deweloper wygląda dobrze.

   • Z drugiej strony, jeśli programista twierdzi, że metoda wydaje się zbyt trudna do przetestowania jednostkowego (nie warta znacznego wysiłku), być może jest to dobra wskazówka, że ​​metoda musi zostać podzielona lub ponownie opracowana, aby przetestować łatwe części. Zazwyczaj są to metody polegające na nietypowych zasobach, takich jak singletony, bieżący czas lub zasoby zewnętrzne, takie jak zestaw wyników bazy danych. Metody te zwykle wymagają przekształcenia w metodę, która pobiera zasób (np. Wywołuje getTime ()) i metodę, która przyjmuje zasób jako argument (np. Przyjmuje znacznik czasu jako parametr). Pozwalam im pominąć testowanie metody, która pobiera zasób, i zamiast tego piszą test jednostkowy dla metody, która teraz bierze zasób za argument. Zwykle sprawia to, że pisanie testu jednostkowego jest znacznie prostsze i dlatego warto pisać.

2. Deweloper musi narysować „linię w piasku” w zakresie kompleksowości testów jednostkowych. Później w fazie rozwoju, gdy tylko znajdziemy błąd, powinni ustalić, czy bardziej kompleksowe testy jednostkowe wykryłyby problem. Jeśli tak, i jeśli takie błędy pojawiają się wielokrotnie, muszą przesunąć „linię” w stronę pisania bardziej kompleksowych testów jednostkowych w przyszłości (zaczynając od dodania lub rozszerzenia testu jednostkowego dla bieżącego błędu). Muszą znaleźć właściwą równowagę.

Ważne, aby uświadomić sobie, testy jednostkowe nie są panaceum i nie ma czegoś takiego jak zbyt wiele testów jednostkowych. W moim miejscu pracy, ilekroć robimy lekcje, nieuchronnie słyszę „musimy napisać więcej testów jednostkowych”. Zarząd kiwa głową, ponieważ „uderzyło ich w głowę, że„ testy jednostkowe ”==„ dobre ”.

Musimy jednak zrozumieć wpływ „większej liczby testów jednostkowych”. Deweloper może pisać ~ N wierszy kodu tygodniowo i musisz dowiedzieć się, jaki procent tego kodu powinien być kodem testu jednostkowego a kodem produkcyjnym. Luźne miejsce pracy może mieć 10% kodu jako testy jednostkowe i 90% kodu jako kod produkcyjny, co daje produkt z wieloma (choć bardzo błędnymi) funkcjami (pomyśl MS Word). Z drugiej strony ścisły sklep z 90% testami jednostkowymi i 10% kodem produkcyjnym będzie miał solidny produkt o bardzo niewielu funkcjach (pomyśl „vi”). Możesz nigdy nie słyszeć raportów o awarii tego ostatniego produktu, ale prawdopodobnie ma to tyle samo wspólnego z tym, że produkt nie sprzedaje się tak dobrze, jak ma to związek z jakością kodu.

Co gorsza, być może jedyną pewnością w rozwoju oprogramowania jest to, że „zmiana jest nieunikniona”. Załóżmy, że ścisły sklep (90% testów jednostkowych / 10% kodu produkcyjnego) tworzy produkt, który ma dokładnie 2 cechy (zakładając, że 5% kodu produkcji == 1 cecha). Jeśli klient przyjdzie i zmieni 1 z funkcji, wówczas ta zmiana spowoduje usunięcie 50% kodu (45% testów jednostkowych i 5% kodu produkcyjnego). Sklep Lax (10% testów jednostkowych / 90% kodu produkcyjnego) ma produkt z 18 funkcjami, z których żadna nie działa bardzo dobrze. Ich klient całkowicie zmienia wymagania dotyczące 4 swoich funkcji. Mimo że zmiana jest 4 razy większa, tylko połowa bazy kodu zostaje zniszczona (~ 25% = ~ 4,4% testów jednostkowych + 20% kodu produkcyjnego).

Chodzi mi o to, że musisz poinformować, że rozumiesz równowagę między zbyt małą i zbyt dużą liczbą testów jednostkowych - zasadniczo że przemyślałeś obie strony problemu. Jeśli potrafisz przekonać swoich rówieśników i / lub zarządzanie tym, zyskujesz wiarygodność i być może masz większą szansę na ich pozyskanie.

Kilkakrotnie bawiłem się testami jednostkowymi i wciąż muszę być przekonany, że biorąc pod uwagę moją sytuację, warto.

Zajmuję się tworzeniem stron internetowych, w których znaczna część logiki polega na tworzeniu, wyszukiwaniu lub aktualizacji danych w bazie danych. Kiedy próbowałem „wyśmiewać” bazę danych do celów testów jednostkowych, stała się bardzo nieuporządkowana i wydawała się trochę bezcelowa.

Kiedy napisałem testy jednostkowe wokół logiki biznesowej, nigdy tak naprawdę nie pomogło mi to na dłuższą metę. Ponieważ w dużej mierze pracuję nad samymi projektami, zwykle intuicyjnie wiem, na które obszary kodu może mieć wpływ coś, nad czym pracuję, i testuję te obszary ręcznie. Chcę jak najszybciej dostarczyć rozwiązanie mojemu klientowi, a testy jednostkowe często wydają się stratą czasu. Wymieniam testy ręczne i sam je przejmuję, zaznaczając je na bieżąco.

Widzę, że może to być korzystne, gdy zespół programistów pracuje nad projektem i aktualizuje sobie nawzajem kod, ale nawet wtedy uważam, że jeśli programiści są wysokiej jakości, dobra komunikacja i dobrze napisany kod często powinny wystarczyć .

Jedną wielką zaletą testów jednostkowych jest to, że służą one jako dokumentacja zachowania kodu. Dobre testy są trochę jak implementacja referencyjna, a członkowie zespołu mogą na nich spojrzeć, aby zobaczyć, jak zintegrować swój kod z twoim.

Testy jednostkowe są warte początkowej inwestycji. Odkąd kilka lat temu zacząłem używać testów jednostkowych, odkryłem kilka rzeczywistych korzyści:

• testowanie regresji usuwa obawy przed wprowadzaniem zmian w kodzie (nic nie przypomina ciepłego blasku, gdy kod działa lub eksploduje przy każdej zmianie)
• przykłady kodu wykonywalnego dla innych członków zespołu (i ciebie za sześć miesięcy ..)
• bezlitosne refaktoryzowanie - jest to niezwykle satysfakcjonujące, spróbuj!

Fragmenty kodu mogą być bardzo pomocne w zmniejszeniu obciążenia związanego z tworzeniem testów. Nie jest trudne tworzenie fragmentów, które umożliwiają utworzenie konturu klasy i powiązanego urządzenia do testów jednostkowych w kilka sekund.

Powinieneś przetestować jak najmniej!

co oznacza, że ​​powinieneś napisać tylko tyle testów jednostkowych, aby ujawnić zamiar. Często się to zmienia. Test jednostkowy kosztuje. Jeśli wprowadzisz zmiany i będziesz musiał zmienić testy, będziesz mniej zwinny. Testy jednostkowe powinny być krótkie i słodkie. Wtedy mają dużą wartość.

Zbyt często widzę wiele testów, które nigdy się nie złamią, są duże i niezgrabne i nie oferują dużej wartości, po prostu spowalniają cię.

Nie widziałem tego w żadnej z pozostałych odpowiedzi, ale zauważyłem, że mogłem debugować o wiele szybciej . Nie musisz przechodzić do szczegółowej analizy aplikacji, wykonując tylko odpowiednią sekwencję kroków, aby dostać się do kodu naprawy, tylko po to, aby stwierdzić, że popełniłeś błąd boolowski i musisz to wszystko powtórzyć. Dzięki testowi jednostkowemu możesz po prostu przejść bezpośrednio do debugowanego kodu.

[Muszę sprawić, że nie mogę zobaczyć powyżej]

„Wszyscy przeprowadzają testy jednostkowe, niekoniecznie zdają sobie z tego sprawę - FAKT”

Pomyśl o tym, piszesz funkcję, która może przeanalizować ciąg znaków i usunąć nowe znaki wiersza. Jako początkujący programista albo uruchamiasz kilka przypadków z poziomu wiersza poleceń, implementując go w Main (), albo walisz wizualny interfejs za pomocą przycisku, powiązaj swoją funkcję z kilkoma polami tekstowymi i przyciskiem i zobacz co się dzieje.

To jest testowanie jednostkowe - podstawowe i źle połączone, ale testujesz fragment kodu w kilku przypadkach.

Piszesz coś bardziej złożonego. Zgłasza błędy, gdy przerzucisz kilka przypadków (testowanie jednostkowe) i debugujesz do kodu i śledzenia. Patrząc na wartości, decydujesz, czy są one dobre, czy złe. To do pewnego stopnia testy jednostkowe.

Testy jednostkowe naprawdę uwzględniają to zachowanie, formalizują je w ustrukturyzowany wzór i zapisują, aby można było łatwo ponownie uruchomić te testy. Jeśli napiszesz „właściwy” testowy przypadek jednostkowy zamiast testowania ręcznego, zajmuje to tyle samo czasu, a może mniej, jak się doświadczasz, i masz możliwość powtarzania go wielokrotnie

Przez lata próbowałem przekonać ludzi, że muszą napisać test jednostkowy swojego kodu. Niezależnie od tego, czy najpierw napisali testy (jak w TDD), czy po zakodowaniu funkcjonalności, zawsze starałem się wyjaśnić im wszystkie zalety testów jednostkowych kodu. Mało kto się ze mną nie zgodził. Nie możesz się nie zgodzić z czymś, co jest oczywiste, a każda inteligentna osoba zobaczy zalety testu jednostkowego i TDD.

Problem z testowaniem jednostkowym polega na tym, że wymaga zmiany zachowania i bardzo trudno jest zmienić zachowanie ludzi. Dzięki słowom wielu ludzi zgodzi się z tobą, ale nie zobaczysz wielu zmian w sposobie, w jaki robią różne rzeczy.

Musisz przekonywać ludzi. Twój osobisty sukces przyciągnie więcej ludzi niż wszystkie argumenty, które możesz mieć. Jeśli zauważą, że nie mówisz tylko o teście jednostkowym lub TDD, ale robisz to, co głosisz, i odnosisz sukcesy, ludzie będą próbować cię naśladować.

Powinieneś również przejąć główną rolę, ponieważ nikt nie pisze testu jednostkowego za pierwszym razem, więc może być konieczne przeszkolenie ich w tym, jak to zrobić, wskazanie drogi i dostępnych narzędzi. Pomóż im, pisząc pierwsze testy, przejrzyj testy, które sami piszą, i pokaż im sztuczki, idiomy i wzorce, których nauczyłeś się na podstawie własnych doświadczeń. Po pewnym czasie sami zaczną dostrzegać korzyści i zmienią swoje zachowanie, aby włączyć testy jednostkowe lub TDD do swojego zestawu narzędzi.

Zmiany nie nastąpią w ciągu nocy, ale przy odrobinie cierpliwości możesz osiągnąć swój cel.

Główną częścią rozwoju opartego na testach, który jest często pomijany, jest pisanie testowalnego kodu. Z początku wydaje się, że to jakiś kompromis, ale odkryjesz, że testowalny kod jest ostatecznie modułowy, łatwy w utrzymaniu i czytelny. Jeśli nadal potrzebujesz pomocy w przekonywaniu ludzi, to ładna prosta prezentacja na temat zalet testowania jednostkowego.

Jeśli istniejąca baza kodu nie nadaje się do testowania jednostkowego, a jest już w produkcji, możesz stworzyć więcej problemów niż rozwiązać, próbując zrefaktoryzować cały kod, aby można go było przetestować jednostkowo.

Zamiast tego lepiej będzie, jeśli będziesz starał się poprawić swoje testy integracyjne. Istnieje wiele kodów, które są po prostu prostsze do napisania bez testu jednostkowego, a jeśli QA może zweryfikować funkcjonalność względem dokumentu wymagań, to gotowe. Wyślij to.

Klasycznym przykładem tego jest moim zdaniem SqlDataReader osadzony na stronie ASPX połączonej z GridView. Cały kod znajduje się w pliku ASPX. SQL jest w procedurze przechowywanej. Co testujesz? Jeśli strona robi to, co powinna, to czy naprawdę należy przeprojektować ją na kilka warstw, aby mieć coś do zautomatyzowania?

Jedną z najlepszych rzeczy w testowaniu jednostkowym jest to, że kod staje się łatwiejszy do testowania podczas jego wykonywania. Istniejący kod utworzony bez testów jest zawsze wyzwaniem, ponieważ ponieważ nie miały one być testowane jednostkowo, nierzadko występuje wysoki poziom sprzężenia między klasami, trudne do skonfigurowania obiekty w klasie - jak wiadomość e-mail wysyłanie referencji usługi - i tak dalej. Ale nie pozwól, by cię to przygnębiło! Przekonasz się, że ogólny projekt kodu poprawi się, gdy zaczniesz pisać testy jednostkowe, a im więcej będziesz testować, tym bardziej będziesz pewny, że wprowadzasz do niego jeszcze więcej zmian bez obawy, że złamiesz aplikację lub wprowadzisz błędy .

Istnieje kilka powodów, aby testować kod jednostkowo, ale w miarę upływu czasu przekonasz się, że czas zaoszczędzony na testowaniu jest jednym z najlepszych powodów, aby to zrobić. W systemie, który właśnie dostarczyłem, nalegałem na przeprowadzenie automatycznych testów jednostkowych, pomimo twierdzeń, że spędziłem znacznie więcej czasu na testowaniu niż na testowaniu systemu ręcznie. Po wykonaniu wszystkich moich testów jednostkowych przeprowadzam ponad 400 przypadków testowych w mniej niż 10 minut i za każdym razem, gdy musiałem dokonać niewielkiej zmiany w kodzie, wystarczyło mi upewnić się, że kod nadal działa bez błędów, ma dziesięć minuty. Czy potrafisz sobie wyobrazić czas poświęcony na ręczne wykonanie tych ponad 400 przypadków testowych?

Jeśli chodzi o testowanie automatyczne - czy to testowanie jednostkowe, czy testowanie akceptacyjne - wszyscy uważają, że marnowanie wysiłku na kodowanie tego, co można zrobić ręcznie, czasem jest marnowane, a czasem jest to prawda - jeśli planujesz uruchomić testy tylko raz. Najlepszą częścią zautomatyzowanych testów jest to, że możesz je uruchomić kilka razy bez wysiłku, a po drugim lub trzecim uruchomieniu już zmarnowany czas i wysiłek są opłacone.

Ostatnia rada to nie tylko testowanie kodu przez jednostkę, ale najpierw rozpoczęcie testowania (więcej informacji w TDD i BDD )

Testy jednostkowe są również szczególnie przydatne, jeśli chodzi o refaktoryzację lub ponowne napisanie kodu. Jeśli masz dobre pokrycie testami jednostkowymi, możesz bez obaw refaktoryzować. Bez testów jednostkowych często trudno jest upewnić się, że niczego nie złamałeś.

W skrócie - tak. Są warte każdej uncji wysiłku ... do pewnego stopnia. Testy są na koniec dnia kodem i, podobnie jak typowy wzrost kodu, testy będą musiały zostać zrefaktoryzowane, aby były łatwe w utrzymaniu i trwałe. Jest tona GOTCHAS! jeśli chodzi o testy jednostkowe, ale człowiek, o, o, o, o, nic, i mam na myśli, że NIC nie upoważnia programisty do wprowadzania zmian z większą pewnością niż bogaty zestaw testów jednostkowych.

W tej chwili pracuję nad projektem ... to jest trochę TDD i większość naszych reguł biznesowych jest zakodowanych jako testy ... mamy teraz około 500 testów jednostkowych. W poprzedniej iteracji musiałem odnowić nasze źródło danych i sposób, w jaki nasza aplikacja komputerowa łączy się z tym źródłem danych. Zajęło mi to kilka dni, cały czas po prostu przeprowadzałem testy jednostkowe, aby zobaczyć, co zepsułem i naprawiłem. Dokonaj zmiany; Zbuduj i uruchom swoje testy; napraw to, co zepsułeś. Umyć, spłukać, powtórzyć w razie potrzeby. To, co tradycyjnie wymagałoby dni kontroli jakości i stresu łodzi, było krótkim i przyjemnym doświadczeniem.

Przygotuj się z góry, trochę dodatkowego wysiłku, a później opłaca się 10-krotnie, gdy musisz zacząć grzebać z podstawowymi funkcjami / funkcjami.

Kupiłem tę książkę - to jest Biblia wiedzy o testowaniu xUnit - to prawdopodobnie jedna z najczęściej używanych książek na mojej półce i codziennie ją przeglądam: link do tekstu

Od czasu do czasu albo ja, albo jeden z moich współpracowników spędzimy kilka godzin, aby dotrzeć do sedna lekko niejasnego błędu, a gdy zostanie znaleziona przyczyna błędu, 90% czasu to kod nie jest testowany jednostkowo. Test jednostkowy nie istnieje, ponieważ deweloper skraca rogi, aby zaoszczędzić czas, ale potem traci to i jeszcze więcej debugowania.

Poświęcenie niewielkiej ilości czasu na napisanie testu jednostkowego może zaoszczędzić wiele godzin przyszłego debugowania.

Pracuję jako inżynier utrzymania słabo udokumentowanej, okropnej i dużej bazy kodu. Chciałbym, żeby ludzie, którzy napisali kod, napisali dla niego testy jednostkowe.
Za każdym razem, gdy wprowadzam zmiany i aktualizuję kod produkcyjny, boję się, że mogę wprowadzić błąd, który nie wziął pod uwagę jakiegoś warunku.
Gdyby napisali test, wprowadzanie zmian w bazie kodu byłoby łatwiejsze i szybsze (jednocześnie baza kodu byłaby w lepszym stanie) ..

Myślę, że testy jednostkowe okazują się bardzo przydatne przy pisaniu api lub frameworków, które muszą trwać wiele lat i być używane / modyfikowane / ewoluowane przez osoby inne niż oryginalne kodery.

Testy jednostkowe są zdecydowanie warte wysiłku. Niestety wybrałeś trudny (ale niestety powszechny) scenariusz, w którym chcesz go wdrożyć.

Najlepszą korzyścią z testów jednostkowych, jakie uzyskasz, jest korzystanie z nich od podstaw - na kilku wybranych, małych projektach miałem szczęście napisać moje testy jednostkowe przed wdrożeniem moich klas (interfejs był już kompletny punkt). Dzięki odpowiednim testom jednostkowym znajdziesz i naprawisz błędy w swoich klasach, gdy są jeszcze w powijakach i nie znajdują się w pobliżu złożonego systemu, w którym bez wątpienia zostaną zintegrowane w przyszłości.

Jeśli twoje oprogramowanie jest zorientowane obiektowo, powinieneś być w stanie dodać testy jednostkowe na poziomie klasy bez większego wysiłku. Jeśli nie masz tyle szczęścia, powinieneś nadal próbować stosować testowanie jednostkowe, gdzie tylko możesz. Upewnij się, że kiedy dodasz nową funkcjonalność, nowe elementy są dobrze zdefiniowane z czytelnymi interfejsami, a przekonasz się, że testy jednostkowe znacznie ułatwią ci życie.

Kiedy powiedziałeś: „nasza baza kodu nie nadaje się do łatwego testowania” jest pierwszą oznaką zapachu kodu. Pisanie testów jednostkowych oznacza, że ​​zwykle piszesz kod inaczej, aby kod był bardziej testowalny. Moim zdaniem jest to dobra rzecz, ponieważ to, co widziałem przez lata w pisaniu kodu, dla którego musiałem pisać testy, zmusiło mnie do opracowania lepszego projektu.

Nie wiem. Wiele miejsc nie wykonuje testów jednostkowych, ale jakość kodu jest dobra. Microsoft przeprowadza test jednostkowy, ale Bill Gates dał niebieski ekran podczas swojej prezentacji.

Napisałem bardzo duży post na blogu na ten temat. Przekonałem się, że same testy jednostkowe nie są warte pracy i zwykle ulegają skróceniu, gdy zbliżają się terminy.

Zamiast mówić o testowaniu jednostkowym z punktu widzenia weryfikacji „test po”, powinniśmy przyjrzeć się prawdziwej wartości znalezionej, gdy postanowiłeś napisać specyfikację / test / pomysł przed implementacją.

Ten prosty pomysł zmienił sposób, w jaki piszę oprogramowanie i nie wrócę do „starej” drogi.

Jak pierwszy test zmienił moje życie

Tak - Testowanie jednostek jest zdecydowanie warte wysiłku, ale powinieneś wiedzieć, że to nie jest srebrna kula. Testowanie jednostkowe jest pracą i będziesz musiał pracować, aby test był aktualizowany i odpowiedni jak zmiany kodu, ale oferowana wartość jest warta wysiłku, jaki musisz włożyć. Możliwość bezkarnego refaktoryzacji jest ogromną korzyścią, ponieważ zawsze możesz zweryfikować funkcjonalność uruchamiając testy po każdym kodzie zmiany. Sztuka polega na tym, aby nie odrywać się od dokładnie tego, co testujesz, ani jak testujesz rusztowania, a kiedy test jednostkowy jest testem funkcjonalnym itp. Ludzie będą się o to spierać godzinami na koniec, a rzeczywistość jest taka, że ​​każde testowanie, które wykonujesz jako swój kod, jest lepsze niż nie robienie tego. Drugi aksjomat dotyczy jakości, a nie ilości - widziałem podstawy kodu z 1000 ' Testy, które są w zasadzie bez znaczenia, ponieważ reszta nie testuje niczego użytecznego ani niczego konkretnego dla danej domeny, takiego jak reguły biznesowe itp. danej domeny. Widziałem również podstawy kodu z 30% pokryciem kodu, ale testy były trafne, znaczące i naprawdę niesamowite, ponieważ testowały podstawową funkcjonalność kodu, dla którego zostały napisane, i wyraziły sposób, w jaki kod powinien być używany.

Jedną z moich ulubionych sztuczek podczas eksploracji nowych frameworków lub baz kodowych jest pisanie testów jednostkowych dla „it”, aby odkryć, jak rzeczy działają. To świetny sposób, aby dowiedzieć się więcej o czymś nowym zamiast czytać suchego dokumentu :)

Niedawno przeszedłem dokładnie to samo doświadczenie w moim miejscu pracy i odkryłem, że większość z nich zna teoretyczne korzyści, ale musiała zostać sprzedana z korzyściami dla nich konkretnie, więc oto punkty, które wykorzystałem (z powodzeniem):

• Oszczędzają czas podczas przeprowadzania testów negatywnych, w których obsługiwane są nieoczekiwane dane wejściowe (wskaźniki zerowe, wartości poza granicami itp.), Ponieważ można to zrobić w jednym procesie.
• Zapewniają natychmiastową informację zwrotną w czasie kompilacji na temat standardu zmian.
• Są one przydatne do testowania wewnętrznych reprezentacji danych, które mogą nie zostać ujawnione podczas normalnego działania.

i ten duży ...

• Być może nie potrzebujesz testów jednostkowych, ale gdy ktoś inny wejdzie i zmodyfikuje kod bez pełnego zrozumienia, może wykryć wiele głupich błędów, które mogą popełnić.

Kilka lat temu odkryłem TDD i od tego czasu pisałem o nim wszystkie moje projekty dla zwierząt. Oszacowałem, że projekt TDD zajmuje mniej więcej tyle samo czasu, co wspólny projekt kowboja, ale mam tak większe zaufanie do produktu końcowego, że nie mogę się oprzeć wrażeniu spełnienia.

Uważam również, że poprawia mój styl projektowania (znacznie bardziej zorientowany na interfejs, na wypadek, gdy muszę wyśmiewać rzeczy razem) i, jak pisze zielony post na górze, pomaga w „zaparciach kodujących”: gdy nie wiesz, co pisać dalej lub masz przed sobą trudne zadanie, możesz pisać małe.

Wreszcie stwierdzam, że zdecydowanie najbardziej użyteczną aplikacją TDD jest debugowanie, choćby dlatego, że opracowałeś już środowisko zapytań, dzięki któremu możesz zmusić projekt do wygenerowania błędu w powtarzalny sposób.

Jedną rzeczą, o której nikt jeszcze nie wspomniał, jest zaangażowanie wszystkich programistów w uruchomienie i aktualizację dowolnego istniejącego automatycznego testu. Zautomatyzowane testy, do których wracasz i które okazały się zepsute z powodu nowego rozwoju, tracą wiele na wartości i sprawiają, że zautomatyzowane testy są naprawdę bolesne. Większość z tych testów nie będzie wskazywać błędów, ponieważ programista przetestował kod ręcznie, więc czas poświęcony na ich aktualizację to tylko marnotrawstwo.

Przekonanie sceptyków, aby nie zniszczyli pracy, którą inni wykonują podczas testów jednostkowych, jest o wiele ważniejsze dla uzyskania korzyści z testów i może być łatwiejsze.

Spędzanie godzin na aktualizowaniu testów, które zepsuły się z powodu nowych funkcji przy każdej aktualizacji z repozytorium, nie jest ani produktywne, ani przyjemne.

Jeśli korzystasz z NUnit, jednym prostym, ale skutecznym demo jest uruchomienie przed nimi własnego zestawu testów NUnit. Widzenie prawdziwego zestawu testów, w ramach którego program ćwiczeń wykonuje trening, jest warte tysiąca słów ...

Testy jednostkowe bardzo pomagają w projektach większych niż jakikolwiek programista może trzymać w głowie. Pozwalają na uruchomienie pakietu testów jednostkowych przed zameldowaniem i stwierdzenie, czy coś zepsułeś. Ogranicza to wiele przypadków, gdy trzeba usiąść i przekręcić kciuki, czekając, aż ktoś naprawi błąd, który zgłosili, lub podejmując problem z cofnięciem zmiany, abyś mógł trochę popracować. Jest również niezwykle cenny przy refaktoryzacji, więc możesz być pewien, że zrefaktoryzowany kod przejdzie wszystkie testy, które wykonał oryginalny kod.

Dzięki pakietowi testów jednostkowych można wprowadzać zmiany w kodzie, pozostawiając pozostałe funkcje nienaruszone. To wielka zaleta. Czy korzystasz z oprogramowania do testów jednostkowych i testów regresji, kiedy kończysz kodowanie nowej funkcji?

Zgadzam się z punktem widzenia przeciwnym do większości tutaj: Nie można pisać testów jednostkowych. Szczególnie ciężkie programowanie prototypów (na przykład AI) jest trudne do połączenia z testami jednostkowymi.