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.
- Do jakich projektów używasz programowania opartego na testach? Czy używasz go tylko do projektów powyżej określonego rozmiaru?
- Czy powinienem go używać, czy nie? Przekonaj mnie!
programming-practices
unit-testing
tdd
Casebash
źródło
źródło
Odpowiedzi:
Ok, kilka zalet TDD:
Prosiłeś o przekonanie, więc były to korzyści. Zobacz to pytanie, aby uzyskać bardziej wyważony obraz.
źródło
Robert C. Martin początkowo przedstawił te punkty - mogę je poprzeć własnym doświadczeniem:
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.
źródło
(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.
źródło
źródło
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.
źródło