Lekcja 17 · Faza 2 · Krok 4 z 6

tdd: red-green-refactor, ale z regułami które robią różnicę

Czwarty krok z zalecanej kolejności README: implementacja. Skill zaczyna od zdania, które warto zapamiętać dosłownie: "TDD is the red → green loop. This skill is the reference that makes that loop produce tests worth keeping." Sam red-green-refactor znasz pewnie już skądinąd — ta lekcja skupia się na regułach, które odróżniają test wart utrzymania od testu, który tylko wygląda jak TDD.

Dobry test kontra zły test

// DOBRY: testuje zachowanie przez publiczny interfejs
test("user can checkout with valid cart", async () => {
  const cart = createCart();
  cart.add(product);
  const result = await checkout(cart, paymentMethod);
  expect(result.status).toBe("confirmed");
});

// ZŁY: testuje szczegóły implementacji
test("checkout calls paymentService.process", async () => {
  const mockPayment = jest.mock(paymentService);
  await checkout(cart, payment);
  expect(mockPayment.process).toHaveBeenCalledWith(cart.total);
});

Rozpoznawalny znak złego testu: psuje się przy refaktorze, mimo że zachowanie się nie zmieniło. Dobry test przeżywa refaktor, bo w ogóle nie wie, jak coś jest zaimplementowane wewnątrz — tylko co jest widoczne z zewnątrz.

Seam: gdzie w ogóle wolno testować

Seam to publiczna granica, przy której obserwujesz zachowanie, nie sięgając do środka. Reguła jest twarda: testujesz tylko przy wcześniej uzgodnionych seamach. Zanim padnie choć jeden test, skill ma zapytać: "What's the public interface, and which seams should we test?" — i dopiero po Twojej odpowiedzi zaczyna pisać.

Trzy anti-patterny

Tautologiczny test naprawiasz, licząc oczekiwaną wartość niezależnie: expect(calculateTotal([{price:10},{price:5}])).toBe(15) zamiast przepisywać wzór sumowania drugi raz. Horizontal slicing to dokładnie odwrotność vertical slices z Lekcji 15 — tu też obowiązuje zasada tracer bullet: jeden test → jedna minimalna implementacja → powtórz, każdy cykl reagujący na to, czego nauczył poprzedni.

Trzy zasady pętli

1. Red przed green — najpierw failing test, potem tylko tyle kodu, żeby przeszedł. Bez wyprzedzania przyszłych testów, bez spekulatywnych funkcji.
2. Jeden plaster naraz — jeden seam, jeden test, jedna minimalna implementacja na cykl.
3. Refaktoring NIE jest częścią pętli — należy do etapu review (skill code-review, dwie lekcje dalej), nie do cyklu red→green.

Sprawdź się