axde
2019-11-19 14:10

Tłumaczę znajomemu (od kilku lat nietechniczny, zarządza projektami, hindusami, wdrożeniami) czym jest TDD w idealnym świecie:

  • Piszesz test zanim napiszesz kod.

Po moim wprowadzeniu pada pytanie (w sumie słuszne jakby się nad tym zastanowić)

  • I jaki jest benefit tego reverse engineeringu zeby najpierw test case taki robic zanim zrobisz kawałek kodu?

Więc tłumaczę krok po kroku:

  • Piszesz test
  • Odpalasz - masz dostać FAIL
  • Piszesz funkcję, metodę, pętlę, interfejs, coś co chcesz przetestować dla jakichś tam wyników, które ma przyjmować dana funkcja/metoda/blablabla (...)
  • Odpalasz test, ma być PASS
  • Robisz refactor tego co napisałeś

Kolega stwierdza:

  • Czyścisz kibel
  • Srasz do czystego kibla
  • Czyścisz kibel ponownie
somekind

To, że nietechniczny kolega nie rozumie to pół biedy, gorzej, że tzw. "programiści" też nie rozumieją.

Sunnydev

@somekind: nie jestem w stanie w to uwierzyć. Z czym Ty miałeś do czynienia?

axde

@Sunnydev: Pewnie India engineering.

no_solution_found

ale Ty mu wytłumaczyłeś jak wygląda proces, ale jaki profit dla biznesu z tego to nie powiedziałeś :)

somekind

@Sunnydev: w co nie jesteś w stanie uwierzyć? W to, że masa programistów, także na tym forum nie widzi zalet w pisaniu testów przed implementacją i nie widzi dla tego sensownego zastosowania?

axde

@no_solution_found: Wytłumaczyłem. Generalnie dyskusja wzięła się z tego, że u niego takie rzeczy robi QA. Ale dogadaliśmy, że jednak nie do końca. ;-)

somekind

QA i TDD? Ale jak? :D

axde

@somekind: U nich QA coś tam jeszcze testuje po wdrożeniu. Nie zagłębiałem się, bo z tego co widzę to u każdego wygląda to inaczej, a gość aspekty techniczne porzucił ponad 4 lata temu więc też średnio go to interesuje - stąd niewiedza.

somekind

QA może testować coś po wdrożeniu, to akurat jeszcze nie jest nic dziwnego. Ale niby jak w TDD?!

danek

@somekind: sprawdza, że nie działa ( ͡° ͜ʖ ͡°)

axde

@somekind: I tak to tam właśnie działa. Po wytłumaczeniu różnicy między testowaniem przez (typowego) QA, a robieniem TDD wszystko się wyjaśniło. Inna sprawa, że u niego w korpo TDD chyba nie istnieje skoro India engineering wrzuca jakieś parametry testowe, i wywala się cały projekt minutę po wdrożeniu ¯\_(ツ)_/¯

TomRZ

Jest jeszcze Behavior-driven development, czyli rozwinięcie TDD

nalik

Trzeba było mu powiedzieć, że pisząc najpierw test opracowuje przypadek użycia, tworzy kontrakt dla API, definiuje oczekiwane wejście, wyjście i zachowanie, a także ma pewność, że nie zabraknie mu czasu na opracowanie testu. Mając jasno zdefiniowane, odpowiednio zawężone wymagania i walidację w postaci testu, można skupić się na implementacji tego co trzeba, zamiast zastanawiać się nad "designem" dopiero podczas implementacji.

Karol191PL

@somekind: To wytłumacz te benefity TDD :P

Kamil Żabiński

Nie, BDD nie jest rozwinięciem TDD. One są ortogonalne. Można mieć BDD, a nie mieć TDD, bo TDD określa kiedy pisać testy, a BDD - jak pisać testy i co testować. Np. testy pisane przez QA często są BDD, ale prawie nigdy nie są TDD

Kamil Żabiński

A Bardzo Dzielny Scrum Master pyta się kto Ci może pomóc

furious programming

@axde: piwo postaw koledze – zasłużył.

somekind

@Karol191PL: zyski są takie, że odpowiednio użyte przyspiesza powstawanie kodu. Ale tego nie zrozumie nikt, kto tak szybko biega z taczką, że nie ma czasu załadować.

Karol191PL

@somekind: Ale w jaki sposób przyśpiesza?

ccwrc

@Karol191PL: bugi widzisz od razu, wykonanie 500 testów może potrwać około sekundy i od razu wiesz co jest nie tak i reagujesz. Poprawiasz błąd w kilka minut zamiast później szukać go godzinę, badać powiązania i kłaść szpachlę, która wytrzymuje do następnego tajemniczego błędu bo testów nie ma.

TomRZ

Na pewno przyspiesza testowanie, a tym samym posrednio tworzenie nowego kodu. Tylko projekt musi osiągnąć pewną wielkość krytyczną, plus musi być to projekt często aktualizowany. Robienie TDD do jakiejś pierdoły mija się z celem.

Karol191PL

@ccwrc: No ok ale jak np. piszesz te 4 nowe metody a następnie do nich testy, no to nie tracisz kontekstu, i tak samo szybko zajmie ci naprawienie ich. @TomRZ Czyli to też zależy od wielkości metody i złożoności logiki w tej metodzie/projekcie w takim razie.

ccwrc

@Karol191PL: Ale dlaczego ale? Właśnie to jest super - masz kontekst, wymagania, wszystko idzie gładko i szybko. A jak jesteś zmuszony coś zmodyfikować (tak, zdarza się) w kodzie sprzed 3 dni to jeśli coś pójdzie nie tak testy wyłapią to od razu. I od razu jest feedback co jest nie tak.

axde

@Karol191PL: chciałbym tylko zauważyć, że najpierw piszesz test, a później logikę właściwą.

ccwrc

@axde: może uściślając: fajnie by było, gdyby najpierw pojawiła się przynajmniej nazwa metody. W teście metoda występuje i można spokojnie brać się za pisanie logiki.

Karol191PL

@ccwrc: No ale chwilka, rozumiem że w tym przypadku metoda już została napisana a zabierasz się za następne metody z taska? No to też możesz pisać test po każdej napisanej metodzie.

ccwrc

@Karol191PL: rozwiń proszę co rozumiesz a czego nie i do czego dokładnie się odnosisz.

wartek01

"I jaki jest benefit tego reverse engineeringu zeby najpierw test case taki robic zanim zrobisz kawałek kodu?" - największą wartością dodaną TDD jest to, że musisz ustalić jak konkretnie funkcja/metoda/klasa musi działać zanim zaczniesz ją pisać. Resztę można olać.

somekind

No to też możesz pisać test po każdej napisanej metodzie. - tak też można i często ma to sens, ale to nie jest TDD. TDD działa w sytuacji, gdy znamy specyfikację, i od początku wiemy co kod ma zrobić i jakich wyników oczekujemy.

BraVolt

Po co robisz testy? Żeby po zakończonym remoncie łazienki nie było niespodzianki, że woda w kiblu nie leci.

ccwrc

@BraVolt: trochę inaczej: żeby gówno płynęło do ścieków a nie do prysznica.

BraVolt

Po co i jak robisz testy montując podtynkowo kibel? Zakładasz, że w nowowybudowanym domu jest aktywne przyłącze wody. Test. Ma być woda, nie cieknąć, nie ma być nawet mała kałuża, w miejscu kibla. Test. Cieknie. Ciągniesz rurę. Jest woda, nie cieknie na izolacji? Zakładasz, że ma być na czym usiąść i czym spłukać. Test, nie ma, instalacja sedesu, test. Ma odpływ być.... i tak dalej. Na koniec płyta gipsowo kartonowa wodoodporna, mają być wymiary zachowane. Test... Mają być położone kafelki. Test... Test First etapami żeby nie położyć płytek a na koniec okaże się, że woda jednak nie płynie. Test First daje dupochron, że dotychczasowa praca nie została w pewnym momencie skopana (wymiary się nie zgadzały, brakło miejsca, to uciąłem tę rurkę albo usunąłem kolanko kiedy kładłem płytki).

axelbest

Odnoszac się do komentarza tego kolegi z posta OP, to jesli nie zastosujemy tej techniki

  1. Czyścisz kibel / 2. Srasz do czystego kibla / 3. Czyścisz kibel ponownie

To możemy mieć sytuację

  1. Nie możesz zrobić kupy, bo kibel jest zatkany i jest narobione "z czubem" :D
BraVolt

Podstawowy błąd to przekonanie, że klient ma być świadomym stosowania TDD. Dla klienta to zawsze będzie zmarnowany ciężko opłacany czas programistów. Auta się rozbija w crashtestach, ma to na pewno wpływ na cenę produktu.Gdyby klientom dać wybór, czy chcą żeby nowy model był crashtestowany czy nie to wybiorą wersję oszczędniejszą (no bo przecież nic się nie stanie, auta jeżdżą po drogach i jest OK). Testy to element produkcji a nie dodatkowy fragment zlecenia który jest nie za bardzo potrzebny klientowi.
Programista w trakcie pracy nad projektem czytał książki, uczestniczył w kursie, dokształcał się w czasie pracy, był na konferencji. Gdyby o tym też szczegółowo informować klienta i próbować mu to wyjaśniać to by marudził dlaczego pracują w firmie "niedouczeni" programiści (pewnie dlatego tyle testują bo są słabi). Niech zrobią zlecenie a dokształcać się będą później.

axde

Sam stosuję sobie TDD od niedawna i powiem szczerze, że o ile sam zrobię sobie założenia do ttestowanej funkcji/metody/errorów/struktur etc. to całkiem fajnie to wygląda. Zupełnie inaczej się myśli w ten sposób gdy najpierw muszę klepnąć sobie założenia później test, a potem napisać właściwy kod. Podoba mi się to niezależnie od benefitów tego rozwiązania. Może faktycznie schodzi dłużej z pisaniem ale chyba później faktycznie są tego profity. Oczywiście nigdy nie miałem z TDD styczności więc na razie piszę własne śmieciowe rzeczy i uczę się tego podejścia ale jestem tym zafascynowany - tak jak nowymi rzeczami, których mogę spróbować.

Jasnowidz

W swojej pierwszej pracy nauczylem sie TDD, ktore stosowalem w miare - binarki mialy po kilkanascie gb, trzeba bylo po kazdej zmianie takie testy liczone w setkach odpalic, mialo to imho gruby sens. Wymagania od poczatku sztywne i konkretne - wiec testy pisalo sie od reki.

W mojej pozniejszej drodze zawodowej (ERPy SAPowe) nie mialo to kompletnie sensu. Zmiany wymagan co godzina, programy wielkosci 100 linii kodu, budzety takie, ze pokrycie testami kodu (Nie wazne czy pisane przed czy po) zerowe.

Nie dziwie sie ze ktos bez styku z technologia tego sensu nie widzi - bo nawet ja go nie widze, przynajmniej nie wszedzie.

somekind

Taki truizm, ale nic nie ma sensu wszędzie. TDD ma sens w określonych przypadkach, w innych sens ma pisanie testów po implementacji, a w jeszcze innych testy jednostkowe w ogóle nie mają sensu.