Nie, nie chodzi mi tu o duży koncern medialny, ale o pewne podejście… hm… odmianę TDD.
Generalnie zauważyłem, że wielu początkujących z programowaniem w Javie po obejrzeniu prezentacji TDD zraża się do samego języka. Wynika to zazwyczaj z faktu, że nie posiadają oni dobrze wykształconego zmysłu postrzegania struktury kodu. Każdy choć trochę doświadczony programista potrafi w miarę gładko zarządzać „kodem z dziurami”. Kod taki zazwyczaj się nie kompiluje, bo brakuje jakiś obiektów, nie ma metod czy interfejsów.
Najładniej widać to przy pisaniu szybkich testów TDD. Gdy zaczynamy tworzyć funkcjonalność to najpierw piszemy test wkładając w niego same nazwy interfejsów, metod czy obiektów. Następnie gdy napiszemy test do końca zaczynamy intensywnie używać narzędzi do automatycznego tworzenia brakujących elementów (w Eclipse ctrl+1 i create new…), po czym zaczynamy implementację. Wymaga to jednak już na starcie jakiejś wizji API, powiązań i nazewnictwa obiektów. To można sobie wyrobić w czasie pracy, ale początkujący nie ma takiego obycia (chyba, że programował wcześniej w czymś innym).

Moje podejście, które zazwyczaj pokazuję osobom początkującym jest trochę inne. Zakładam najpierw, że mają napisać program w oparciu tylko o interfejsy. Wymusza to logiczny podział kodu. Poza tym konieczne jest pisanie czarno-skrzynkowe. Programista wie co dostaje na wejściu i na wyjściu. Nie jest to może idealne podejście, bo zaczynamy kodować przed napisaniem testów, ale bardzo ułatwia rozumienie jak kod działa.

TDD po mojemu nazywa się ITI od:

  • Interfejsy
  • Testy
  • Implementacja

Taka kolejność jest przyjaźniejsza piszącemu i pozwala na pisanie testów bez konieczności późniejszego usuwania błędów kompilacji. W dodatku można wtedy tworzyć większe partie testów na raz.