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

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!

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.

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.

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

• 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

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.