Rozwój oparty na testach - przekonaj mnie! [Zamknięte]

30

Wiem, że niektórzy ludzie są masowymi zwolennikami rozwoju opartego na testach. W przeszłości używałem testów jednostkowych, ale tylko do testowania operacji, które można łatwo przetestować lub które, jak sądzę, będą prawdopodobnie poprawne. Wydaje się, że pełne lub prawie całkowite pokrycie kodu zabiera dużo czasu.

  1. Do jakich projektów używasz programowania opartego na testach? Czy używasz go tylko do projektów powyżej określonego rozmiaru?
  2. Czy powinienem go używać, czy nie? Przekonaj mnie!
Casebash
źródło
3
Mam tyle problemów z pisaniem testów. Doszło do tego, że wszystko weryfikuję ręcznie.
TheLQ
Spójrz na to pytanie: stackoverflow.com/questions/301693/…
systempuntoout
1
@TheLQ ... spróbuj powiedzieć mojemu klientowi, że moje oprogramowanie do sterowania lotem jest w porządku, ponieważ dokonałem ręcznej weryfikacji kodu :-)
Andrew,

Odpowiedzi:

32

Ok, kilka zalet TDD:

  1. Oznacza to, że skończysz z większą liczbą testów. Wszyscy lubią mieć testy, ale niewiele osób lubi je pisać . Wbudowanie pisania testów do przepływu programistycznego oznacza, że ​​otrzymujesz więcej testów.
  2. Pisanie do testu zmusza do myślenia o testowalności twojego projektu, a testowalny projekt jest prawie zawsze lepszym projektem. Nie jest dla mnie do końca jasne, dlaczego tak się dzieje, ale moje doświadczenie i doświadczenie większości ewangelistów TDD wydaje się to potwierdzać.
  3. Oto badanie , w którym napisano, że chociaż napisanie TDD zajmuje trochę więcej czasu, zwrot z inwestycji jest dobry, ponieważ otrzymujesz kod o wyższej jakości, a zatem mniej błędów do naprawienia.
  4. Daje ci pewność refaktoryzacji. To wspaniałe uczucie, że można zmienić jeden system, nie martwiąc się o złamanie wszystkiego innego, ponieważ jest dość dobrze objęty testami jednostkowymi.
  5. Prawie nigdy nie dostajesz powtarzającego się błędu, ponieważ każdy znaleziony powinien przejść test, zanim zostanie naprawiony.

Prosiłeś o przekonanie, więc były to korzyści. Zobacz to pytanie, aby uzyskać bardziej wyważony obraz.

Fishtoaster
źródło
10
„projekt do przetestowania jest prawie zawsze lepszym projektem” - myślę, że głównym powodem tego jest fakt, że testowalny kod jest ogólnie modułowy i ma uproszczone zależności.
Skilldrick
„Wszyscy lubią mieć testy, ale niewiele osób lubi je pisać”. - czy to naprawdę prawda? Wydaje się, że fajnie byłoby wymyślić dobre testy i spróbować uruchomić testowane oprogramowanie.
DarenW
3
@ DarenW- Nie wiem o tobie, ale wolę, aby rzeczy działały, niż je łamać. Powiedział, że ktoś, kto nie myśleć tak, jak proponował to hella-wartościowa jako tester. Na świecie nie ma wystarczającej liczby ludzi zajmujących się kontrolą jakości.
Fishtoaster
Dostaję błąd 403 Fornidden na tym pliku PDF
Neil N
Zaktualizowany do tego, co jestem pewien, że był taki sam pdf (to było kilka lat temu)
Fishtoaster
11

Robert C. Martin początkowo przedstawił te punkty - mogę je poprzeć własnym doświadczeniem:

  • Automatycznie zbudujesz zestaw testów regresji z testami jednostkowymi.
  • Prawie nigdy nie będziesz tracił czasu na debugowanie, ponieważ jeśli kodujesz się w dziurze, łatwiej jest cofnąć kod do momentu, w którym ostatni test przeszedł pomyślnie, niż złamać debugger.
  • Co kilka minut sprawdzasz, czy Twój kod działa - całość (lub przynajmniej całe zachowanie objęte testami, które, jeśli wykonujesz TDD, stanowi bardzo wysoki procent).

Prawie cały czas robię TDD, niezależnie od tego, czy pracuję nad produkcją, czy gramem kodu; W dzisiejszych czasach trudno mi kodować w inny sposób.

Paddyslacker
źródło
6

(Oświadczenie: Nie robię prawie żadnych elementów interfejsu użytkownika, więc nie mogę omawiać TDD dla interfejsów użytkownika.)

Korzystam z TDD praktycznie we wszystkim, co robię, od prostych aplikacji po całe stosy SIP.

Nie używam TDD w starej witrynie PHP, którą przejęłam. Boli mnie brak testów. Uważam, że to bardzo denerwuje przypadkowe zerwanie części witryny, ponieważ nie mam zestawu testów regresji, który mówi mi, że coś złamałem. Klient nie ma dla mnie budżetu na (a) napisanie testów dla bazy kodu i (b) w trakcie procesu, aby kod był testowalny w pierwszej kolejności, więc po prostu to pogodziłem.

Frank Shearar
źródło
1
  • Ilekroć twój klient może być dostarczany bardziej skutecznie (prawdopodobnie będzie dobrze odnosił się do testów - i przynajmniej ograniczy dyskusję na końcu projektu)
  • Ilekroć zajmie to więcej czasu, informuj współtwórców o WSZYSTKIM w kodzie, niż wkładaj wysiłek w budowanie testu - i jest to wcześniej, niż myślisz
Tobiasopdenbrouw
źródło
-1

Co? Brak negatywnej odpowiedzi !?

Oświadczenie: Nie jestem anty-testowaniem jednostkowym. Kiedy ludzie mówią TDD, zakładam, że mają na myśli wersję brzmiącą jak choroba, w której piszą testy, zanim napiszą kod dla 80-100% całego kodu, który piszą.

Argumentowałbym:

  • To umożliwia. Jeśli łapanie problemów z regresją jest dla ciebie tak dużym problemem, że w pełni automatyczna TDD od samego początku wydaje się opłacalna, pisanie testów dla każdego ostatniego napisanego kodu może w rzeczywistości pomóc zignorować prawdziwy problem.

  • Pomaga ludziom zignorować prawdziwy problem. Po naprawieniu jednego błędu zamienia się w grę w walenie w kret, w której dwa kolejne wyskakują, architektura wieje. Skupiać. Skoncentruj się na prawdziwym problemie. Oglądanie moli zanim trzeba je bić, jest fajne, ale nie powinieneś tam być.

  • Zjada dużo czasu. Od czasu do czasu trafiam na błędy. Nie uderzyłem tak wielu, że warto prefiksować każdą nową rzecz, którą piszę, testując ją. Problemy z połowem, w których mogą się zdarzyć. Obsługuj błędy, aby były łatwe do zdiagnozowania. Uprawomocnić. Testuj w kluczowych punktach nakładania się / wąskiego gardła. Ale za głośne wołanie nie testuj każdego ostatniego gettera i setera w czymś, co prawdopodobnie nie powinno było mieć ich na pierwszym miejscu.

  • Koncentracja na projekcie: Absolutnie nie ma mowy, aby nawet dobry programista napisał najlepszy kod, jaki mógł, gdy skupiał się również na teście. Jeśli wydaje się, że jest to jedyny sposób na uzyskanie przyzwoitego projektu, polecam zapoznanie się z powyższym na temat „koncentrowania się na prawdziwym problemie”.

  • Makro-projektowanie nie powiodło się: podstawa kodu w mojej obecnej pracy jest pełna interfejsów, które nigdy nie są używane więcej niż raz i masowych naruszeń podstawowej zasady DRY, które w końcu zacząłem rozumieć, kiedy zdałem sobie sprawę, że ludzie piszą dla środowisk testowych i testują w generał. Testowanie nie powinno prowadzić do głupiej architektury. Nie, tak naprawdę nie ma nic bardziej skalowalnego lub godnego korporacji w kopiowaniu i wklejaniu 20 plików, a następnie wprowadzaniu jedynie znaczących zmian w dwóch z nich. Chodzi o to, aby rozdzielić obawy, a nie podzielić je na pół. Cruft i bezcelowa abstrakcja będą cię kosztować więcej niż nie, nigdy nie będziesz mieć 95% zasięgu.

  • Jest bardzo popularny i bardzo wielu ludzi naprawdę go lubi. Jeśli nie jest to wystarczający powód, aby przynajmniej odgadnąć i / lub zweryfikować bzdury jakiejkolwiek technologii przed adopcją, naucz się paranoi.

Erik Reppen
źródło
Zwolennicy Bah czytają tylko nagłówek Q, a nie treść.
Erik Reppen
1
Przegłosowałem i przeczytałem wszystko. wiele wad, które wskazałeś, w rzeczywistości rozwiązują najbardziej podstawowe książki TDD. TDD nie oznacza „po prostu napisz tyle testów studpi WET Un-SOLID, ile możesz i nigdy nie myśl o projektowaniu”. Myślę, że ta odpowiedź jest nieuczciwym wprowadzaniem w błąd TDD. jeśli twoja aplikacja stanie się bałaganem, ponieważ ludzie kopiują i wdrażają okropne projekty, to jest to problem projektowy. TDD to tylko przepływ pracy i nie zajmujesz się nim.
sara