Test-Driven Development (TDD)

TDD to podejście do programowania, które opiera się na cyklicznym procesie pisania testów przed implementacją kodu. Metoda ta składa się z trzech etapów:

1. Red – Napisz test, który nie przechodzi.

• Najpierw piszesz test jednostkowy, który opisuje nową funkcjonalność.
• Test musi nie przejść (czyli zakończyć się błędem), ponieważ funkcjonalność jeszcze nie istnieje.
• To potwierdza, że test działa i ma sens.

2. Green – Napisz minimalny kod, który przechodzi test.

• Implementujesz najprostszy możliwy kod, który sprawia, że test przechodzi.
• Nie martwisz się jeszcze o jakość kodu – ważne, aby test był zielony (przeszedł).

3. Refactor – Ulepsz kod, nie psując testów.

• Porządkujesz i optymalizujesz kod (usuwanie duplikacji, poprawa nazw, struktury).
• Wszystkie testy muszą nadal przechodzić.
• Ten etap zapewnia jakość i utrzymywalność kodu.

TDD z perspektywy testera

1. Współpraca z deweloperami.

• Tester może wspierać tworzenie przypadków testowych (np. przez scenariusze akceptacyjne).
• Wspólne rozumienie wymagań pomaga tworzyć lepsze testy jednostkowe i integracyjne.

2. Zrozumienie zakresu testów TDD.

• TDD koncentruje się głównie na testach jednostkowych (ang. unit tests).
• Testerzy uzupełniają ten proces testami wyższego poziomu:
  • Testy integracyjne.
  • Testy systemowe.
  • Testy eksploracyjne.

3. Weryfikacja pokrycia przypadków brzegowych.

• Testerzy mogą pomóc w identyfikacji przypadków brzegowych i wyjątków, które warto objąć testami.
• TDD nie zawsze gwarantuje pokrycie wszystkich scenariuszy — tu wchodzi rola testera.

4. Regresja i dokumentacja.

• Testy TDD działają jako automatyczna dokumentacja kodu.
• Ułatwiają wykrywanie regresji — każda zmiana w kodzie natychmiast pokazuje, czy coś zostało złamane.

Testerzy mogą stosować podobne podejście: ATDD i BDD.

Testerzy często korzystają z ATDD (Acceptance Test-Driven Development) i BDD (Behavior-Driven Development):

• ATDD: testy akceptacyjne pisane przed kodem.
• BDD: opis zachowań systemu w języku zrozumiałym dla wszystkich interesariuszy (np. Gherkin / Given-When-Then).

Korzyści z TDD.

TDD to nie tylko testowanie, to projektowanie.

• TDD wymusza lepszy design — kod jest zazwyczaj bardziej modularny, testowalny i pozbawiony zbędnych zależności.
• Testy pełnią rolę klienta kodu – dzięki temu projektujesz API swojego komponentu zanim go zaimplementujesz.

TDD a pokrycie testami.

• TDD naturalnie prowadzi do wysokiego pokrycia kodu testami (ang. code coverage).
• Ale wysokie pokrycie ≠ dobre testy – ważna jest jakość przypadków testowych, nie tylko ilość.

TDD wspiera ciągłą integrację (CI).

• Testy pisane w TDD doskonale wspierają procesy Continuous Integration.
• Dzięki nim błędy są wychwytywane wcześnie, a zmiany w kodzie są bezpieczniejsze.

TDD wzmacnia komunikację w zespole.

• Testy jednostkowe mogą służyć jako źródło wiedzy – inne osoby w zespole widzą, jak ma działać dana funkcja.
• Pomaga to uniknąć błędnych założeń i nieporozumień w interpretacji wymagań.