Czym jest Test Driven Development? Wprowadzenie i przykłady

Artykuł ten jest wprowadzeniem do zupełnych podstaw Test Driven Development, dzięki któremu każdy może poznać podstawy tej techniki. TDD docenią szczególnie te osoby, które mają już dosyć mozolnego szukania błędów w programie i chciałyby przejść na trochę wyższy poziom.

[Szpiczaga]

Odbiegając trochę od samego TDD, to dziwi mnie, że ciągle pojawia się frazes jak to znalezienie błędu w późniejszej fazie zabiera więcej czasu i są z tego tytułu większe straty. Czasem znalezienie błędu jest szybkie dopiero gdy poskłada się kilka komponentów w całość i zrobi testy integracyjne, rozkminiane wszystkich scenariuszy wcześniej to jest wtedy strata czasu i kasy. Natomiast na produkcji, o ile błąd może być kosztowny (nie zawsze tak jest, ale

[qj0n]

@Szpiczaga: To był raczej problem waterfalla - jak zakończysz fazę designu i masz tonę diagramów bez kodu to potem jak robiąc kod znajdziesz błąd, który wymaga zmiany designu (albo gorzej - podczas fazy testów) to masz do powtórzenia zmiany w designie, kodzie i testy.
Ale to właśnie skrócenie tego czasu poprzez różne agile'owe metody powoduje, że nawet jak błąd znajdziesz później to tylko kilka zmian i już fix jest na

[Lipka91]

@Szpiczaga: TDD pomaga wychwycić płapki myślenia. Np bardzo podstawowym casem jest co jeśli apka zwrócu błąd (w przypadku komunikacji z serwisami). TDD pozwala na obsłużenie go wcześniej w odpowiedni sposób. W systemach pisanych na kolanie błędy są obsługiwane przez użytkownika.
Pytanie co się bardziej opłaca. Testować na produkcji czy pisać stabilny kod. W przypadku posiadania testów(dobrze zaplanowanych) mamy pewność ze po refactoringu nie ma tragedi z naszą apką.

[E.....r]

Fajnie, tylko z reguły żaden budżet na projekt tego nie zakłada :p No i kolejny problem, pisać testy to jedno a pisać dobre testy to dwa a pisać testy byle by statystyki pokrycia się zgadzały to trzy :p

[qj0n]

@Ekscentryczny_obserwator: no ale przy TDD nie ma sensu patrzeć na pokrycie, to w ogóle nie w tę stronę...

No i TDD obniża koszt wytworzenia produktu. Jeśli potrzebujesz większego budżetu na TDD to znaczy, że coś robisz nie tak...

[qj0n]

@Ekscentryczny_obserwator: W teorii co? Sam używam TDD tak w 30-50% kodu i w większości przypadków pozwala szybciej wyjść na produkcję i zdarza się, że wyłapuje potem regresje. Być może gdybym jechał 100% TDD to średnio wyszedłbym gorzej niż 0%, no ale nie wszystko jest gwoździem, więc nie zawsze młotek jest dobry, a jednak czasem właśnie jest najlepszym narzędziem...

[Cierniostwor]

W niektórych projektach w firmie stosuje tą metodę, jest świetna. Najlepiej sprawdza się tam gdzie testy automatyczne trwają po kilka-kilkanaście sekund, jeśli dłużej to ta metoda zaczyna niesamowicie męczyć.

[IOException]

Tylko metody formalne. Wszystkie te TDD, E2E i inne klasyfikacje czy metodologie ktore to tylko hinduscy doktorzy nauk znaja - nie zapewnia poprawnego dzialania programu.

[qj0n]

@IOException: ...bo nie do tego służą?

[IOException]

@qj0n: A niby do czego. Do zapewnienia ze program nie dziala niepoprawnie?

[r.....r]

Będę stosował jak będę programistą

[sirobert]

@r3solver: taaa

[wermesz]

Niestety, ale to wszystko ładnie wygląda w teorii. W praktyce testy jednostkowe zajmują więcej czasu niż właściwa implementacja. W ostatnich latach narodził się jednak ich fanatyzm. Pełno jest zespołów dumnie twierdzących, że robią testy jednostkowe gdzie te testy z jednostkowymi i zasadami TDD nie mają nic wspólnego. A jak się obruszają jak im o tym powiesz ( ͡° ͜ʖ ͡°) Jak jeszcze dodasz, że TDD nie za bardzo

[wermesz]

@qj0n: Robienie UT po fakcie oczywiście też się w tym wszystkim pojawia. Zespół jednak dalej fanatycznie twierdzi, że robi TDD ( ͡° ͜ʖ ͡°)

[123xD]

@wermesz: Moim głównym kryterium dla pisania testów jest właśnie wydajność, bez nich jestem kilka razy wolniejszy... Nawet głupie odpalenie aplikacji żeby zobaczyć swoje zmiany zajmuje rząd wielkości więcej czasu niż uruchomienie testu (który uruchamia się sam ( ͡° ͜ʖ ͡°) )

I nie mówię tutaj o szukaniu błędów

[veranoo]

Agile i TDD nigdy nie będą ze sobą działać.

[qj0n]

@veranoo: Tylko dlaczego twórca XP, Kent Beck (skąd wziął się TDD) był sygnatariuszem manifestu? TDD było jedną z metodyk współtworzącą oryginalny ruch Agile...

[RobotKuchenny9000]

szkoda tylko ze TDD to buzzword pod którym nie kryje się nic. TDD nie ma żadnego wpływu na nic :)

[qj0n]

@RobotKuchenny9000: Co masz na myśli pisząc "klasyczne podejście do testowania"?

[qj0n]

@RobotKuchenny9000: Najbardziej klasyczne podejście jakie znam to podejście waterfallowe, ale jak porównasz TDD do waterfalla to od razu zauważysz skrócenie czasu release'ów. Więc zakładam, że pisząc "klasyczne" masz na myśli coś nowszego niż waterfall (mimo, że sam TDD ma już 20 lat, więc jest jak najbardziej "klasyczny").

Być może masz na myśli "klasyczne unit testy", pisane np. w modelu V czy tam piramidzie/rożku. W takim przypadku UT rzeczywiście są zaraz