Jeśli TDD dotyczy projektowania, dlaczego go potrzebuję? [Zamknięte]

Guru TDD coraz bardziej mówią nam, że TDD nie polega na testach, ale na projektowaniu . Znam więc niektórych programistów, którzy tworzą naprawdę świetny projekt bez TDD. Czy powinni wtedy ćwiczyć TDD?

TDD nie tylko pomaga mi dojść do najlepszego ostatecznego projektu, ale pomaga mi dotrzeć tam przy mniejszej liczbie prób.

Kiedyś miałem problem z dwoma lub trzema nożami, zanim zdecydowałem, który projekt uważam za najlepszy. Teraz dokładnie tyle samo czasu spędzam na pisaniu testów i skupianiu się na poprawnym projekcie. Jako bonus pozostawia mi zestaw powtarzalnych testów. Zdobyć!

To powiedziawszy, nieuchronnie będą ludzie, dla których TDD nic nie oferuje. Dopóki mają na końcu zautomatyzowane, powtarzalne testy, nie ma sprawy.

Ten konkretny guru TDD tak naprawdę nie chce powiedzieć, że TDD jest procesem projektowym (chociaż wiele osób niestety tak to interpretowało). Wiadomość tutaj jest taka, że ​​zastosowanie takiego procesu, jak TDD, jeśli zrobisz to dobrze , poprawi ogólny projekt.

Podstawowa koncepcja jest znacznie starsza niż TDD; projektowanie pod kątem testowalności . Jeśli rygorystycznie przestrzegasz zasad SOLID , w szczególności zasady pojedynczej odpowiedzialności , kod będzie bardzo łatwy do przetestowania. Z drugiej strony, jeśli masz tendencję do nieco niechlujstwa w swoim projekcie, prawdopodobnie znajdziesz proces pisania testów jednostkowych, aby zmusić cię do robienia tego częściej, aby uniknąć frustracji (a) zastanawiania się, co trzeba zostać przetestowanym i (b) poświęcając więcej czasu na konfigurowanie zależności niż na pisanie rzeczywistych testów.

Nie ma podążać TDD, aby czerpać korzyści z tego, ale to nie pomocy pisać testy wcześnie - najlepiej bardzo szybko po zaimplementować klasę, jeśli nie przed lub w trakcie. Jeśli czekasz zbyt długo, ryzykujesz testy „brudnej hybrydy”, o której mówi autor, które nie mają dużej wartości, ponieważ są kruche i mają tendencję do pękania podczas nieszkodliwego refaktoryzacji - nie wspominając już o powiększaniu -skala przeprojektowuje niezwykle trudny proces.

Nie możesz wiedzieć, czy naprawdę projektujesz testowalność, jeśli nie piszesz testów, a przypadkowe „testy funkcji” z jedynie 15% pokryciem kodu nie liczą się.

Oczywiście możesz tworzyć dobre projekty bez pisania ani jednego testu - ale czy na pewno są to świetne projekty? Skąd wiesz, jeśli nie są one wyraźnie określone w testach? Testy ujawniają wiele problemów i chociaż proces kontroli jakości może znaleźć widoczne błędy, nie wykryją złych decyzji projektowych.

Prosta odpowiedź pochodząca od osoby starającej się nauczyć TDD: Nie potrzebujesz jej, ale główną korzyścią, jaką daje, jest po prostu pewność : pewność, że aplikacja działa. Pewność, że przypadki użycia są spełnione. Pewność, że twoja logika jest dobra dla modułu „Foobar”. Pewność, że Twój kod jest odpowiednio skonstruowany, aby był łatwy w utrzymaniu i rozszerzalny przez sześć miesięcy, kiedy CEO chce dodać nową szaloną funkcję, o której czytał. Ufaj, że wraz z rozwojem aplikacji położono fundamenty, aby architektura się nie rozpadła ani nie wymagała mnóstwa niechlujnych hacków, aby sforsować nowe funkcje.

Zdaję sobie sprawę, że powyższe brzmiało trochę ewangelicznie, ale tak widzę korzyści z TDD. Nawet jeśli potrafisz tworzyć dobre, solidne, dobrze zaprojektowane projekty za pomocą TDD, zmusza twoją rękę do robienia rzeczy we właściwy sposób, a następnie udowadnia, że ​​wszystko jest zrobione dobrze, a co ważniejsze stanowi podstawę do utrzymania porządku. Od bardzo niewielkiej liczby rzeczy, którymi zajmowałem się TDD, użycie go zmusiło mnie do wyczyszczenia kodu i przestrzegania odpowiednich koncepcji inżynierii oprogramowania, w przeciwnym razie zrobiłbym „najszybszą możliwą rzecz”, co często powodowało niechlujny kod „hack”.

Mogę rozmawiać tylko z własnego doświadczenia. TDD przyniosło mi kilka rzeczy, których wcześniej nie miałem w zestawie narzędzi do nawyków projektowania. Chociaż warto jeszcze raz powiedzieć, że TDD nie jest rozwiązaniem wszystkiego. Zawsze staram się oddzielić wdrożenie gotowe do eksploracji i produkcji. TDD w fazie eksploracji absolutnie nie jest potrzebny, a nawet zwalnia. Z drugiej strony kod gotowy do produkcji przynosi szereg korzyści, które w krótkim i długim okresie są bardzo cenne dla zdrowia psychicznego programistów i karmy projektu.

• TDD sprawia, że ​​zastanawiam się przed wdrożeniem, co jest zwykle bardzo dobrą praktyką, która zapobiega wielu rozwiązaniom typu „strzelaj i zapomnij”
• Sprawia, że ​​myślę małymi porcjami problemu, zmuszając mnie do rozdzielenia rozwiązania małych, pasujących do siebie kawałków.
• To sprawia, że ​​piszę bardzo oddzielony kod, ponieważ za każdym razem, gdy muszę stubować / wyśmiewać / fałszować coś, co nie pasuje do problemu, naturalnie rzucam jeden „WTF, dlaczego miałbym to robić, jeśli nie muszę być z tym związany” . I to sprawia, że ​​lepiej rozumiem powiązania między rzeczami.
• Daje mi zestaw łatwo wykonywalnych kontroli mojego kodu, więc nie muszę przechodzić przez bolesny styl debugowania kodu „var_dump”, „p”, „pp”, „echo”. Po prostu zgłasza, co jest nie tak, a kiedy nie. A jeśli nie mam jeszcze czeku, wystarczy dodać prosty test, aby to sprawdzić w kółko.
• Daje mi to pewność, że mój kod działa, jeśli wszystkie testy przejdą przed wdrożeniem. Następnie zamiast jeść paznokcie, jem ciasto i piję kawę i cieszę się popołudniami.
• Testy na wysokim poziomie są bardzo miłe w przypadkach, gdy trzeba coś refaktoryzować. Jeśli mój moduł musi udostępniać pewne funkcje światu zewnętrznemu i opracowałem testy funkcjonalne / integracyjne / ogórkowe, aby udowodnić, że działa poprawnie, będę bardzo odważny, aby zreformować piekło z tego kodu. Kilka razy miałem do czynienia z kodem, który nie miał testów i musiałem go przefiltrować. W takim przypadku w praktyce były dwa sposoby. 1) upuść kod 2) pomiń zmiany i pozostaw go bez zmian.

Jest jedna rzecz, której TDD nie naprawia. Jeśli nie wiesz, jak zbudować budowany obiekt, TDD nie opracuje dla ciebie rozwiązania. Musisz mieć z grubsza „projekt” lub przegląd problemu i rozwiązania. TDD sprawi, że zaimplementujesz go w bardziej elegancki i łatwy w utrzymaniu sposób dzięki kodowi wyższej jakości.

W końcu wolę myśleć w kategoriach BDD, które opierają się na praktykach TDD. BDD zmusza mnie do wdrożenia rozwiązania przy użyciu słownictwa domeny i lepszego dopasowania oprogramowania do problemu.

Może istnieć wiele sposobów na osiągnięcie doskonałego projektu i istnieje wiele różnych interpretacji tego, co stanowi „wielki” - a nawet „dobry”. Podejrzewam, że większość TDDerów nie zgodziłaby się z tobą co do definicji - że jeśli spojrzymy na kod, który uważasz za świetny, uznalibyśmy go za niezbyt dobry. TDD doprowadza nas do niektórych bardzo specyficznych cech, które rzadko występują w kodzie innym niż TDD.

Testowalność jest oczywiście jedną z tych cech i nadrzędną. Niezwykle małe metody i klasy są być może cechą podrzędną, co prowadzi do doskonałego nazewnictwa. Być może znasz programistów, którzy osiągają te cechy bez TDD, ale ja nie.