Definicja #
TDD (Test-Driven Development) to technika wytwarzania oprogramowania opracowana przez Kenta Becka w ramach metodologii Extreme Programming (XP). Odwraca tradycyjny porządek pracy: zamiast pisać kod, a potem testy — najpierw piszemy test, który określa oczekiwane zachowanie.
Cykl TDD składa się z trzech kroków (tzw. Red-Green-Refactor):
- Red — napisz test dla nowej, jeszcze nieistniejącej funkcjonalności. Test musi się nie powieść (czerwony), bo kod nie istnieje.
- Green — napisz minimalną ilość kodu produkcyjnego, która sprawi, że test przejdzie (zielony). Nie optymalizuj — tylko spraw, żeby działało.
- Refactor — popraw kod (usuń duplikaty, popraw nazewnictwo, uprość strukturę), upewniając się, że testy nadal przechodzą.
TDD wymusza pisanie kodu testowalnego z definicji — skoro test musi być napisany przed kodem, kod musi być zaprojektowany tak, aby dał się przetestować. Prowadzi to naturalnie do luźnego powiązania komponentów (loose coupling) i stosowania wzorców jak Dependency Injection.
TDD jest często mylone z samym testowaniem — w rzeczywistości to przede wszystkim technika projektowania oprogramowania. Testy są efektem ubocznym, a nie celem samym w sobie.
Zastosowania #
TDD stosuje się do:
- Implementacji logiki biznesowej, gdzie wymagania są jasno określone i można je wyrazić jako asercje testowe
- Tworzenia bibliotek i komponentów wielokrotnego użytku — TDD zapewnia czysty, dobrze odizolowany interfejs API
- Pracy nad kodem legacy — pisanie testów przed refaktoryzacją chroni przed regresją
- Algorytmów i funkcji czystych — szczególnie łatwo testowalnych w stylu TDD
- Środowisk Agile z ciągłą integracją — szybkie testy jednostkowe dają natychmiastowy feedback w CI/CD
Ścieżka nauki #
Przed nauką TDD warto znać podstawy frameworka testowego w swoim języku (np. JUnit dla Javy, NUnit/xUnit dla C#, pytest dla Pythona, Jest dla JS) oraz rozumieć czym jest test jednostkowy.
Zacznij od:
- Cykl Red-Green-Refactor — ćwicz na prostych przykładach (Kata): FizzBuzz, kalkulator, Roman Numerals
- Asercje i ich struktura: Arrange-Act-Assert (AAA)
- Mocki i stuby — izolacja jednostki od zależności zewnętrznych
Następnie poznaj:
- Kata TDD — regularne ćwiczenia na platformach jak Cyber-Dojo, Kata-Log, Exercism
- Różnica między TDD a BDD — kiedy stosować każde podejście
- Testowanie poza jednostkami: integracyjne i kontraktowe testy w podejściu TDD
- Narzędzia: Mockito (Java), NSubstitute (C#), Jest mocks (JS)
FAQ #
- Czy TDD spowalnia programowanie?
- Na początku — tak, bo trzeba pisać więcej kodu. Długoterminowo TDD przyspiesza, bo redukuje czas debugowania, ułatwia refaktoryzację i zapobiega regresji. Doświadczeni praktycy TDD twierdzą, że piszą kod szybciej właśnie dzięki TDD.
- Czym różni się TDD od BDD?
- TDD skupia się na jednostkach kodu i jest pisany z perspektywy programisty. BDD (Behavior-Driven Development) rozszerza TDD o język naturalny (Gherkin: Given-When-Then), skierowany do biznesu i QA. BDD jest komunikacją między rolami, TDD jest techniką implementacji.
- Czy TDD nadaje się do każdego rodzaju kodu?
- TDD sprawdza się doskonale dla logiki biznesowej i algorytmów. Jest trudniejszy do stosowania dla kodu UI, kodu związanego z zewnętrznymi systemami bez dobrego mockowania oraz przy bardzo exploracyjnym programowaniu, gdy wymagania nie są jasne.
- Ile zarabia programista znający TDD?
- TDD jest umiejętnością cenioną w seniorskich rolach. Senior Developer stosujący TDD i czysty kod zarabia w Polsce od 16 000 do 28 000 zł brutto. TDD jest częstym wymaganiem w firmach z dojrzałą kulturą inżynieryjną.