Czy testy jednostkowe są warte wysiłku? [zamknięte]

Testy jednostkowe są jak chodzenie na siłownię.Wiesz, że to dla ciebie dobre, wszystkie argumenty mają sens, więc zaczynasz ćwiczyć. Jest początkowy pośpiech, co jest świetne, ale po kilku dniach zaczynasz się zastanawiać, czy warto się trudzić. Masz godzinę wolnego dnia, żeby się przebrać i biegać na kole chomika i nie jesteś pewien, czy naprawdę zyskujesz coś innego niż obolałe nogi i ręce.

Potem, po może jednym lub dwóch tygodniach, tak jak bolesność odchodzi, zbliża się Wielki termin. Musisz spędzać każdą budzącą się godzinę, próbując wykonać "użyteczną" pracę, więc wyciąć zbędne rzeczy, takie jak chodzenie na siłownię. Wypadasz z nałogu, a gdy skończy się Wielki termin, wracasz do punktu wyjścia. Jeśli uda ci się wrócić do siłowni w ogóle, czujesz się tak samo obolały, jak byłeś po raz pierwszy poszedł.

Trochę poczytasz, żeby sprawdzić, czy robisz coś nie tak. Zaczynasz czuć się trochę irracjonalnie złość wobec wszystkich sprawnych, szczęśliwych ludzi wychwalających cnoty ćwiczeń. Zdajesz sobie sprawę, że nie masz wiele wspólnego. Nie muszą jechać 15 minut z drogi, aby przejść do siłowni; jest jeden w ich budynku. Nie muszą kłócić się z nikim o korzyści płynące z ćwiczeń; jest to po prostu coś, co każdy robi i akceptuje jako ważne. Kiedy zbliża się Wielki termin, nie powiedziano im, że ćwiczenia są niepotrzebne tak samo, jak twój szef poprosi cię, abyś przestał jem.

Tak więc, aby odpowiedzieć na twoje pytanie, testy jednostkowe są zwykle warte wysiłku, ale ilość wymaganego wysiłku nie będzie taka sama dla wszystkich. testowanie jednostkowe może wymagać ogromnego wysiłku, jeśli masz do czynienia z bazą kodu spaghetti w firmie, która nie w rzeczywistości ceni jakość kodu. (Wielu menedżerów wyśpiewuje pochwały testów jednostkowych, ale to nie znaczy, że będą się o to starać, gdy to ma znaczenie.)

Jeśli próbujesz wprowadź testy jednostkowe do swojej pracy i nie widzisz wszystkich promieni słonecznych i tęczy, których się spodziewałeś, nie obwiniaj się. Być może będziesz musiał znaleźć nową pracę, aby testy jednostkowe naprawdę działały dla Ciebie.

Najlepszy sposób na przekonanie... Znajdź błąd, napisz dla niego test jednostkowy, Napraw błąd.

Jest mało prawdopodobne, aby ten konkretny błąd pojawił się ponownie, i możesz to udowodnić swoim testem.

Jeśli zrobisz to wystarczająco dużo, inni szybko się zorientują.

Thetalkingwalnut pyta:

Jakie są dobre sposoby na przekonanie sceptycznych programistów w zespole o wartości testów jednostkowych?

Wszyscy tutaj postawią na wiele powodów, dla których testy jednostkowe są dobre. Jednak uważam, że często najlepszym sposobem, aby przekonać kogoś do czegoś, jest wysłuchanie jego argumentu i zaadresowanie go punkt po punkcie. Jeśli wysłuchasz ich i pomożesz im zwerbalizować ich obawy, możesz rozwiązać każdy z nich i być może przekonwertować je do swojego punktu widzenia(lub przynajmniej pozostawić je bez nogi, aby stać). 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.

Testy jednostkowe są narzędziem, jak każde inne i powinny być zastosowane w taki sposób, że korzyści (wyłapywanie błędów) przewyższają koszty (wysiłek ich napisania). Nie używaj ich, jeśli/tam, gdzie nie mają sensu i pamiętaj, że są tylko częścią twojego arsenału narzędzi (np. inspekcje, twierdzenia, analizatory kodu, metody formalne itp.). To co mówię moim programistom Jest Takie:

1. Mogą pominąć pisanie testu dla metody, jeśli mają dobry argument, dlaczego nie jest to konieczne (np. zbyt proste, aby było warto lub zbyt trudne, aby było warto) oraz w jaki sposób metoda będzie inaczej weryfikowana (np. inspekcja, twierdzenia, metody formalne, testy interaktywne/integracyjne). Muszą wziąć pod uwagę, że niektóre weryfikacje, takie jak inspekcje i formalne dowody, są wykonywane w pewnym momencie, a następnie muszą być powtarzane za każdym razem, gdy kod produkcji zmienia się, podczas gdy testy jednostkowe i twierdzenia mogą być używane jako testy regresyjne(pisane raz, a następnie wykonywane wielokrotnie). Czasem się z nimi zgadzam, ale częściej będę dyskutował o tym, czy metoda jest naprawdę zbyt prosta lub zbyt trudna do testu jednostkowego.

   • Jeśli programista twierdzi, że metoda wydaje się zbyt prosta, aby zawieść, czy nie warto poświęcić 60 sekund niezbędnych do napisania prostego 5-liniowego testu jednostkowego? Te 5 linijek kodu będzie działać co noc (robisz nocne buildy, prawda?) na następny rok lub dłużej i będzie warte wysiłku, jeśli nawet raz zdarzy się złapać problem, który mógł zająć 15 minut lub dłużej, aby zidentyfikować i debugować. Poza tym pisanie easy unit tests zwiększa liczbę testów jednostkowych, co sprawia, że programista wygląda dobrze.

   • Z drugiej strony, jeśli deweloper twierdzi, że metoda wydaje się zbyt trudna do przetestowania jednostkowego (nie warta wymaganego znacznego wysiłku), być może jest to dobra wskazówka, że metoda musi zostać podzielona lub zrefakturowana, aby przetestować łatwe części. Zazwyczaj są to metody, które opierają się na nietypowych zasobach, takich jak singletony, bieżący czas lub zasoby zewnętrzne, takie jak wynik bazy danych gotowi. Metody te zazwyczaj muszą być zrefakturowane do metody, która pobiera zasób (np. wywołuje getTime ()) i metody, która pobiera zasób jako argument (np. pobiera znacznik czasu jako parametr). Pozwoliłem im pominąć testowanie metody, która pobiera zasób i zamiast tego napisać test jednostkowy dla metody, która teraz bierze zasób jako argument. Zazwyczaj sprawia to, że pisanie testu jednostkowego jest znacznie prostsze i dlatego warto je napisać.

2. Programista musi narysować "linię w piasku" w tym, jak kompleksowe powinny być ich testy jednostkowe. W późniejszym czasie, gdy znajdziemy błąd, powinni ustalić, czy bardziej kompleksowe testy jednostkowe wykryłyby problem. Jeśli tak i jeśli takie błędy pojawią się wielokrotnie, muszą przesunąć "linię" w kierunku 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ę.

Its important to zdaj sobie sprawę, że testy jednostkowe nie są srebrną kulą i istnieje coś takiego jak zbyt wiele testów jednostkowych. W moim miejscu pracy, za każdym razem, gdy wyciągamy wnioski, nieuchronnie słyszę "musimy napisać więcej testów jednostkowych". Kierownictwo kiwnie głową, ponieważ został uderzony w ich głowach, że "testy jednostkowe" = = "dobry".

Musimy jednak zrozumieć wpływ "większej liczby testów jednostkowych". Programista może pisać tylko ~N linijek kodu tygodniowo i trzeba się dowiedzieć jaki procent tego kodu powinien być kod testu jednostkowego vs kod produkcji. Luźne miejsce pracy może mieć 10% kodu jako testy jednostkowe i 90% kodu jako kod produkcyjny, co skutkuje produktem z wieloma (choć bardzo wadliwymi) funkcjami (pomyśl o 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"). Być może nigdy nie usłyszysz doniesień o tym ostatnim produkcie, ale prawdopodobnie ma to tyle wspólnego z produktem, który nie sprzedaje się bardzo tak samo jak ma to związek z jakością kodu.

Chodzi mi o to, że musisz przekazać, że rozumiesz tę równowagę między zbyt małym a zbyt dużym testowaniem jednostkowym - zasadniczo, że przemyślałeś obie strony problem. Jeśli uda Ci się przekonać do tego swoich rówieśników i / lub kierownictwo, zyskasz wiarygodność i być może masz większe szanse na ich pozyskanie.

Wiele razy bawiłem się testami jednostkowymi i nadal muszę być przekonany, że jest to warte wysiłku, biorąc pod uwagę moją sytuację.

Tworzę strony internetowe, gdzie duża część logiki wiąże się z tworzeniem, pobieraniem lub aktualizowaniem danych w bazie danych. Kiedy próbowałem "wyśmiewać" bazę danych do celów testów jednostkowych, zrobiło się bardzo niechlujnie i wydawało się trochę bezcelowe.

Kiedy pisałem testy jednostkowe wokół logiki biznesowej, nigdy mi to nie pomogło na dłuższą metę. Bo Ja w dużej mierze pracuję nad samymi projektami, Zwykle wiem intuicyjnie, które obszary kodu mogą być dotknięte przez coś, nad czym pracuję, i testuję te obszary ręcznie. Chcę jak najszybciej dostarczyć klientowi rozwiązanie, a testy jednostkowe często wydają się stratą czasu. Wymieniam testy manualne i sam je przeglądam, odkładając je na później.

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

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

Testy jednostkowe są warte początkowej inwestycji. Od kiedy zacząłem używać testów jednostkowych kilka lat temu, znalazłem pewne realne korzyści:

• Badanie regresji usuwa strach przed dokonywanie zmian w kodzie (nie ma nic jak ciepły blask widzianego kodu pracować lub eksplodować za każdym razem, gdy zmiana jest made)
• przykłady kodu wykonywalnego dla innych członków zespołu (i siebie w pół roku..)
• bezlitosne refaktoryzacja - to jest niesamowicie satysfakcjonujące, spróbuj!

Urywki kodu mogą być bardzo pomocne w ograniczeniu kosztów tworzenia testów. Nie jest trudno stworzyć urywki, które umożliwiają utworzenie konturu klasy i powiązanego urządzenia do testowania jednostek w ciągu kilku sekund.

Powinieneś testować jak najmniej!

Oznacza to, że powinieneś napisać wystarczająco dużo testów jednostkowych, aby ujawnić intencję. To często staje się przesłonięte. Testy jednostkowe Cię kosztują. 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 zepsują, są duże i niezdarne i nie oferują wiele wartości, po prostu kończą się spowolnieniem.

Nie widziałem tego w żadnej innej odpowiedzi, ale jedną rzeczą, którą zauważyłem, jest to, że mogłem debugować o wiele szybciej . Nie musisz przeglądać aplikacji z odpowiednią sekwencją kroków, aby dostać się do kodu, który naprawisz, tylko po to, aby znaleźć błąd logiczny i zrobić to wszystko ponownie. Dzięki testowi jednostkowemu możesz po prostu wejść bezpośrednio do kodu, który debugujesz.

[mam punkt do zrobienia, że nie mogę zobaczyć powyżej]

"każdy testuje, niekoniecznie zdaje sobie z tego sprawę-fakt"

Pomyśl o tym, piszesz funkcję, która może parsować łańcuch znaków i usuwać nowe znaki linii. Jako początkujący programista możesz albo uruchomić kilka przypadków z linii poleceń, implementując je w Main() lub walnąć razem wizualny front end z przyciskiem, powiązać swoją funkcję z kilkoma polami tekstowymi i przyciskiem i zobaczyć, co się stanie.

Że jest testowanie jednostkowe-podstawowe i źle złożone, ale testujesz kawałek kodu dla kilku przypadków.

Piszesz coś bardziej złożonego. Rzuca błędy, gdy rzucasz kilka przypadków przez (testowanie jednostkowe) i debugujesz w kodzie i śledzisz. Patrzysz na wartości w trakcie przechodzenia i decydujesz, czy są one dobre, czy złe. Jest to do pewnego stopnia testowanie jednostkowe.

Testowanie jednostkowe to naprawdę przyjęcie tego zachowania, sformalizowanie go w zorganizowany wzór i zapisanie go tak, aby może łatwo ponownie uruchomić te testy. Jeśli napiszesz "właściwy" przypadek testu jednostkowego, a nie testowanie ręczne, zajmie to tyle samo czasu, a może mniej czasu, gdy zdobędziesz doświadczenie, i masz go do powtórzenia ponownie i ponownie

Od lat staram się przekonać ludzi, że muszą napisać unit test dla ich 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 korzyści płynące z posiadania testów jednostkowych dla kodu. Prawie nikt się ze mną nie zgadzał. Nie można się nie zgodzić z czymś, co jest oczywiste, a każda mądra osoba zobaczy korzyści z 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 Wiele osób zgodzi się z tobą, ale nie zobaczysz wielu zmian w sposobie, w jaki robią rzeczy.

Musisz przekonać ludzi robiąc. Twój osobisty sukces pochłonie więcej ludzi niż wszystkie argumenty, które możesz mieć. Jeśli zobaczą, że nie mówisz tylko o teście jednostkowym lub TDD, ale robisz to, co głosisz i odnosisz sukcesy, ludzie będą starali się cię naśladować.

Należy również podjąć się roli głównej ponieważ nikt nie pisze testu jednostkowego za pierwszym razem, więc być może będziesz musiał nauczyć ich, jak to zrobić, pokazać im drogę i dostępne narzędzia. Pomóż im podczas pisania pierwszych testów, przejrzyj testy, które piszą samodzielnie, i pokaż im sztuczki, idiomy i wzory, których nauczyłeś się dzięki własnym doświadczeniom. Po pewnym czasie zaczną dostrzegać korzyści samodzielnie i zmienią swoje zachowanie, aby włączyć testy jednostkowe lub TDD do swoich skrzynka narzędziowa.

Zmiany nie będą się zdarzać w nocy, ale przy odrobinie cierpliwości możesz osiągnąć swój cel.

Główną częścią test-driven development, która jest często pomijana, jest pisanie testowalnego kodu. Na początku wydaje się to pewnym kompromisem, ale odkryjesz, że testowalny kod jest również ostatecznie modularny, możliwy do utrzymania i czytelny. Jeśli nadal potrzebujesz pomocy w przekonywaniu ludzi to {[2] } jest miłą, prostą prezentacją na temat zalet testów jednostkowych.

Jeśli twoja istniejąca baza kodu nie nadaje się do testów jednostkowych, a jest już w produkcji, możesz stworzyć więcej problemów niż rozwiązać, próbując refaktoryzować cały kod, aby mógł być testowany jednostkowo.

Być może lepiej będzie włożyć wysiłki w poprawę testów integracyjnych zamiast. Istnieje wiele kodu, który jest po prostu prostszy do napisania bez testu jednostkowego, a jeśli QA może zweryfikować funkcjonalność w stosunku do dokumentu wymagań, to koniec. Wyślij to.

Klasycznym tego przykładem w moim umyśle jest SqlDataReader osadzony na stronie ASPX połączonej z GridView. Kod jest w pliku ASPX. SQL jest w procedurze składowanej. Co testujesz jednostkowo? Jeśli strona robi to, co powinna, czy naprawdę powinieneś przeprojektować ją na kilka warstw, aby mieć coś do automatyzacji?

Jedną z najlepszych rzeczy w testowaniu jednostkowym jest to, że Twój kod będzie łatwiejszy do przetestowania, gdy to zrobisz. Istniejący wcześniej kod stworzony bez testów jest zawsze wyzwaniem, ponieważ nie był przeznaczony do testowania jednostkowego, nie jest rzadkością wysoki poziom sprzężenia między klasami, trudne do skonfigurowania obiekty wewnątrz klasy-jak odniesienie do usługi wysyłania wiadomości e - mail-i tak dalej. Ale nie pozwól, aby to cię pogrążyło! Zobaczysz, że ogólny projekt kodu stanie się lepszy, gdy zaczniesz pisz testy jednostkowe, a im więcej testujesz, tym bardziej będziesz mieć pewność, że wprowadzasz w nim jeszcze więcej zmian bez obawy o złamanie aplikacji lub wprowadzenie błędów.

Istnieje kilka powodów, dla których warto przetestować swój kod, ale w miarę upływu czasu przekonasz się, że czas, który oszczędzasz na testowaniu jest jednym z najlepszych powodów, aby to zrobić. W systemie, który właśnie dostarczyłem, nalegałem na zautomatyzowane testy jednostkowe pomimo twierdzeń, że poświęcę dużo więcej czasu na testy niż bym testując system ręcznie. Po wykonaniu wszystkich testów jednostkowych uruchomiłem ponad 400 przypadków testowych w mniej niż 10 minut, a za każdym razem, gdy musiałem dokonać małej zmiany w kodzie, wystarczyło dziesięć minut, aby upewnić się, że kod nadal działa bez błędów. Czy możesz sobie wyobrazić czas, który można spędzić, aby uruchomić te 400 + spraw testowych ręcznie?

Jeśli chodzi o testy automatyczne - czy to testy jednostkowe, czy testy akceptacyjne - każdy uważa, że marnowanie czasu na kodowanie tego, co można zrobić ręcznie, i czasami jest to prawda - jeśli planujesz przeprowadzić testy tylko raz. Najlepszą częścią zautomatyzowanych testów jest to, że można je uruchomić kilka razy bez wysiłku, a po drugim lub trzecim uruchomieniu, czas i wysiłek, który zmarnowałeś , jest już opłacony.

Ostatnią radą byłoby nie tylko jednostkowe przetestowanie kodu, ale także pierwsze wykonanie testu (zobacz TDD i BDD Po Więcej)

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

W skrócie-tak. Są warte każdego wysiłku... do pewnego stopnia. Testy są, na koniec dnia, nadal kodem i podobnie jak typowy wzrost kodu, twoje testy będą musiały zostać zrefakturowane, aby były utrzymywalne i trwałe. Tam jest tona GOTCHAS! jeśli chodzi o testy jednostkowe, ale man oh man oh man, nic, I mam na myśli nic nie upoważnia dewelopera do dokonywania zmian bardziej pewnie niż bogaty zestaw testów jednostkowych.

Właśnie pracuję nad projektem.... jest to trochę TDD, a większość naszych zasad biznesowych jest encapuslated jako testy... mamy teraz około 500 testów jednostkowych. W tej poprzedniej iteracji musiałem zmienić nasze źródło danych i sposób, w jaki nasza aplikacja desktopowa łączy się z tym źródłem danych. Zajęło mi to kilka dni, Cały czas robiłem testy jednostkowe, żeby zobaczyć, co zepsułem i naprawiłem. Dokonaj zmiany; Zbuduj i uruchom testy; napraw to, co zepsułeś. Umyć, spłukać, powtórzyć w razie potrzeby. Co tradycyjnie zajęłoby dni QA i łodzi obciążenia stresu było zamiast krótkie i przyjemne doświadczenie.

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

Kupiłem tę książkę - jest to Biblia xUnit testing knowledge - to chyba jedna z najczęściej cytowanych książek na mojej półce i codziennie ją przeglądam: link text

Czasami albo ja albo jeden z moich współpracowników spędzi kilka godzin na dotarciu do dna nieco niejasnego błędu i gdy przyczyna błędu zostanie znaleziona, 90% czasu, gdy kod nie jest testowany jednostkowo. Test jednostkowy nie istnieje, ponieważ dev skraca rogi, aby zaoszczędzić czas, ale potem traci to i 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 konserwator słabo udokumentowanej, okropnej i dużej bazy kodu. Szkoda, że ludzie, którzy napisali kod, nie napisali do niego testów jednostkowych.
Za każdym razem, gdy dokonuję zmiany i aktualizuję kod produkcyjny boję się, że mogę wprowadzić błąd za to, że nie rozważałem jakiegoś warunku.
Gdyby napisali test, dokonywanie zmian w bazie kodu byłoby łatwiejsze i szybsze.(jednocześnie baza kodu byłaby w lepszym stanie)..

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

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

Najlepszą korzyścią z testów jednostkowych jest to, że używasz ich od podstaw - w kilku wybranych, małych projektach miałem szczęście napisać testy jednostkowe przed wdrożeniem klas (interfejs był już kompletny w tym momencie). Dzięki odpowiednim testom jednostkowym znajdziesz i naprawisz błędy w swoich klasach podczas wciąż są w powijakach i nie są w pobliżu złożonego systemu, z którym bez wątpienia zostaną zintegrowani w przyszłości.

Jeśli Twoje oprogramowanie jest solidnie zorientowane obiektowo, powinieneś być w stanie dodać testy jednostkowe na poziomie klasy bez zbytniego wysiłku. Jeśli nie masz tyle szczęścia, nadal powinieneś próbować włączyć testy jednostkowe, gdzie tylko możesz. Upewnij się, że po dodaniu nowej funkcjonalności nowe elementy są dobrze zdefiniowane za pomocą przejrzystych interfejsów i znajdziesz testy jednostkowe ułatwi Ci życie.

Kiedy powiedziałeś, "nasza baza kodów nie nadaje się do łatwego testowania" jest pierwszą oznaką zapachu kodu. Pisanie testów jednostkowych oznacza, że zazwyczaj 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 przedstawienia lepszego projektu.

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

Napisałem bardzo duży wpis na blogu na ten temat. Odkryłem, że samo testowanie jednostkowe nie jest warte pracy i zwykle jest skracane, gdy zbliżają się terminy.

Zamiast mówić o testach jednostkowych z punktu widzenia weryfikacji "test-after", powinniśmy przyjrzeć się prawdziwej wartości znalezionej podczas pisania specyfikacji / testu / pomysłu przed implementacją.

Ten prosty pomysł zmienił sposób pisania oprogramowania i nie wróciłbym do "starego" sposobu.

Jak test pierwszy rozwój zmienił moje życie

Tak - testy jednostkowe są zdecydowanie warte wysiłku, ale powinieneś wiedzieć, że to nie Srebrna kula. Testowanie jednostkowe jest pracą i będziesz musiał pracować, aby test był aktualizowany i odpowiedni, ponieważ zmienia się kod, ale oferowana wartość jest warta wysiłku, który musisz włożyć. Możliwość bezkarnego refakturowania jest ogromną korzyścią, ponieważ zawsze możesz zweryfikować funkcjonalność, uruchamiając testy po dowolnym kodzie zmiany. Sztuczka polega na tym, aby nie przywiązywać zbyt dużej wagi do dokładnie testowanej jednostki pracy lub do tego, jak jesteś wymagania testowe rusztowania i kiedy test jednostkowy jest naprawdę testem funkcjonalnym, itp. Ludzie będą się kłócić o te rzeczy przez wiele godzin, a rzeczywistość jest taka, że wszelkie testy, które wykonujesz, gdy piszesz kod, są lepsze niż nie robienie tego. Drugi aksjomat dotyczy jakości, a nie ilości - widziałem bazy kodu z 1000 testami, które są zasadniczo bez znaczenia, ponieważ reszta tak naprawdę nie testuje niczego użytecznego ani niczego konkretnego, jak reguły biznesowe itp. Ja widziałem również bazy kodowe z 30% pokryciem kodu, ale testy były istotne, znaczące i naprawdę niesamowite, ponieważ testowali podstawową funkcjonalność kodu, dla którego został napisany i wyrażali, jak kod powinien być używany.

Jedną z moich ulubionych sztuczek podczas odkrywania nowych frameworków lub baz kodowych jest pisanie testów jednostkowych dla "it", aby dowiedzieć się, jak to działa. To świetny sposób, aby dowiedzieć się więcej o czymś nowym zamiast czytać suchego Doca:)

Ostatnio przeszedłem przez dokładnie to samo doświadczenie w moim miejscu pracy i okazało się, że większość z nich zna teoretyczne korzyści, ale musiała zostać sprzedana na świadczenia do nich konkretnie, więc oto punkty, które wykorzystałem (z powodzeniem): {]}

• oszczędzają one czas podczas wykonywania testów ujemnych, gdzie obsługujesz nieoczekiwane dane wejściowe (wskaźniki null, wartości poza granicami, itp.), ponieważ możesz to wszystko zrobić w jednym procesie.
• zapewniają natychmiastową informację zwrotną w czasie kompilacji dotyczącą standard zmian.
• są użyteczne do testowania wewnętrznych reprezentacji danych, które mogą nie być narażone podczas normalnego trybu pracy.

I ten duży...

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

Odkryłem TDD kilka lat temu i od tego czasu napisałem wszystkie moje projekty z jego użyciem. Oszacowałem, że potrzeba mniej więcej tego samego czasu, aby TDD projekt, jak potrzeba, aby kowboj go razem, ale mam tak zwiększone zaufanie do produktu końcowego, że nie mogę pomóc poczucie spełnienia.

Uważam również, że poprawia to mój styl projektowania (znacznie bardziej zorientowany na interfejs, na wypadek, gdybym musiał kombinować) i, jak pisze zielony post na górze, pomaga w " kodowaniu zaparcia": kiedy nie wiesz, co napisać dalej, lub masz przed sobą trudne zadanie, możesz pisać małe.

Wreszcie, uważam, że zdecydowanie najbardziej przydatna aplikacja TDD jest w debugowaniu, choćby dlatego, że już opracowałeś Framework pytający, za pomocą którego możesz poprowadzić projekt do wytworzenia błędu w powtarzalny sposób.

Jedna rzecz, o której nikt jeszcze nie wspomniał, to zobowiązanie wszystkich programistów do uruchomienia i aktualizacji istniejących automatycznych testów. Zautomatyzowane testy, do których wracasz i które są uszkodzone z powodu nowego rozwoju, tracą wiele wartości i sprawiają, że automatyczne 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 spędzony na ich aktualizacji jest po prostu stratą.

Przekonywanie sceptyków, by nie niszczyli pracy inni robią na unit-testy są o wiele ważniejsze dla uzyskania wartości z testów i może być łatwiejsze.

Spędzanie godzin na aktualizowaniu testów, które zostały przerwane z powodu nowych funkcji za każdym razem, gdy aktualizujesz z repozytorium, nie jest ani produktywne, ani Zabawne.

Jeśli używasz NUnit jednym prostym, ale skutecznym demo jest uruchomienie przed nimi własnego zestawu testów NUnit. Zobaczenie prawdziwego zestawu testów dającego bazę kodową trening jest warte tysiąc słów...

Testowanie jednostkowe bardzo pomaga w projektach, które są większe niż jakikolwiek deweloper może utrzymać w swojej głowie. Pozwalają one uruchomić zestaw testów jednostkowych przed checkin i dowiedzieć się, czy coś złamał. To zmniejsza lot na przypadki konieczności siedzieć i kręcić kciukami, czekając na kogoś innego, aby naprawić błąd, który zgłosił, lub przechodząc do kłopotów z powrotem ich zmiany, dzięki czemu można zrobić trochę pracy. Jest również niezwykle cenny w refaktoryzacji, więc możesz być pewien, że zrefakturowany kod przechodzi wszystkie testy, które zrobił oryginalny kod.

Z unit test suite można wprowadzać zmiany w kodzie, pozostawiając resztę funkcji nienaruszoną. To wielka zaleta. Czy używasz unit test sutie i regresji Test suite, gdy kiedykolwiek skończysz kodowanie nowej funkcji.

Zgadzam się z punktem widzenia przeciwnego większości tutaj: dobrze jest nie pisać testów jednostkowych Szczególnie programowanie ciężkie dla prototypów (na przykład sztuczna inteligencja) jest trudne do połączenia z testowaniem jednostkowym.