Testy jako specyfikacja

Prowadzę obecnie dwa projekty zespołowe, w których piszemy kod w trzyosobowych zespołach, starając się podążać za metodą TDD. Pisanie kodu w grupie i dzielenie zadania na mniejsze moduły to wyzwanie samo w sobie, a tutaj jeszcze dodajemy dodatkową komplikację - projekt zostaje rozpisany na etapy, w ramach których przyrasta.

Każdy etap powinien być samodzielny na tyle, aby można go było przetestować. Bo najpierw ustalamy logikę i funkcje, później piszemy dokumentację oraz testy. Testy mają sprawdzać czy działają wszystkie krytyczne funkcje, pola klas itp. Implementacja jest na samym końcu i po prostu ma za zadanie zaświecić testy na zielono. To ciekawy sposób pisania, na pewno wolniejszy niż standardowy, ale podoba mi się fakt, że regularnie zastanawiamy się nad stanem projektu, planujemy rozwój no i - przynajmniej teoretycznie mamy kompletne testy i dokumentację. 

 Sporo commitów w tych projektach to zmiany w testach czy dokumentacji, chodzi o odpowiednią czytelność, a sam kod roboczy no cóż... robimy czasem refaktor, ale ważniejsze jest wdrażanie kolejnych funkcji. O tyle łatwiej z refaktorem, że są odpowiednie testy przygotowane, więc niełatwo coś zepsuć ;)