Test‑Driven Development (TDD)

Test‑Driven Development (z ang. Test‑Driven Development) to technika programistyczna opierająca się na testowaniu jednostkowym, w której najpierw pisze się testy, a dopiero potem – kod spełniający te testy. TDD jest jednym z filarów zwinnych metodologii, szczególnie popularnym w programowaniu obiektowym i w środowiskach wykorzystujących ciągłą integrację.

Historia

Idea TDD wywodzi się z ruchu Extreme Programming (XP) zapoczątkowanego na przełomie lat 90. XX wieku. Pierwsze opisane zasady pojawiły się w publikacji Kenta Becka Test‑Driven Development: By Example z 2002 roku, w której przedstawił on prosty, trzyetapowy cykl: Red‑Green‑Refactor. Od tego czasu technika została przyjęta w wielu innych metodykach Agile, w tym w Scrum, oraz zaadaptowana do licznych języków programowania przy pomocy frameworków takich jak JUnit, xUnit czy RSpec.

Podstawowy cykl – Red‑Green‑Refactor

1. Red (czerwony) – napisz niepowodzeniowy test jednostkowy, który opisuje wymaganą funkcjonalność. Test powinien niepowodzeniowo zakończyć się, co potwierdza, że dana funkcja nie istnieje lub nie jest jeszcze zaimplementowana.
2. Green (zielony) – zaimplementuj minimalny kod niezbędny do tego, aby test przeszedł pomyślnie. Kładzie się nacisk na szybkość, a nie na elegancję.
3. Refactor (refaktoryzacja) – udoskonal powstały kod, zachowując wszystkie istniejące testy w stanie „zielonym”. Dzięki temu kod staje się czytelny, utrzymywalny i niepowtarzalny.

Kluczowe zasady

• Testy przed kodem – testy definiują wymagania zanim pojawi się implementacja.
• Małe, iteracyjne kroki – każdy cykl obejmuje niewielką, jasno określoną funkcjonalność.
• Szybka informacja zwrotna – natychmiastowe wykrycie błędów dzięki automatycznemu uruchamianiu testów.
• Utrzymanie wysokiej jakości kodu – dzięki stałej refaktoryzacji kod pozostaje czysty i łatwy w utrzymaniu.

Korzyści

• Lepsza jakość kodu i mniejsza liczba regresji.
• Dokumentacja w postaci testów jednostkowych, co ułatwia zrozumienie wymagań nowym członkom zespołu.
• Ułatwiona refaktoryzacja i ciągła poprawa architektury.
• Wspomaganie ciągłej integracji i szybkie wykrywanie błędów w fazie kodowania.

Wady i ograniczenia

• Wymaga dyscypliny i doświadczenia – niedoświadczony programista może napisać niewłaściwe testy.
• Na początku zwiększa koszt początkowy projektu ze względu na czas potrzebny na tworzenie testów.
• Nie sprawdza się w projektach z bardzo luźno zdefiniowanymi wymaganiami lub w prototypowaniu, gdzie szybkie zmiany są priorytetem.

Popularne narzędzia i frameworki

W zależności od języka programowania, programiści wykorzystują różne biblioteki do TDD:

• Java – JUnit, TestNG
• .NET – xUnit.net, NUnit
• Python – unittest, pytest
• Ruby – RSpec
• JavaScript – Jest, Mocha

Powiązane koncepcje

Test‑Driven Development jest częścią szerszego ekosystemu praktyk zwinnych i programistycznych:

• Behavior‑Driven Development (BDD) – rozwija TDD o testy opisujące zachowanie systemu z perspektywy użytkownika.
• Continuous Delivery – korzysta z TDD w celu zapewnienia, że każda wersja jest testowana i gotowa do wdrożenia.
• DevOps – integruje praktyki TDD w procesie automatyzacji i monitoringu.

Przykładowy kod (Java + JUnit)

import static org.junit.Assert.*;
import org.junit.Test;

public class KalkulatorTest {
    @Test
    public void testDodaj() {
        // Red – test nie istnieje jeszcze
        Kalkulator kalk = new Kalkulator();
        assertEquals(5, kalk.dodaj(2, 3));
    }
}

Po uruchomieniu testu otrzymujemy błąd (Red). Następnie implementujemy metodę dodaj, aby test przeszedł (Green), i w końcu refaktoryzujemy kod, zachowując wszystkie testy w stanie zielonym.

Zobacz także

• Extreme Programming
• Behavior‑Driven Development (BDD)
• Continuous Integration
• Refaktoryzacja
• Scrum