TDD z Copilotem: red-green-refactor z AI

Czego się nauczysz

• Jak używać Copilota jako wsparcia dla TDD, a nie zamiennika dyscypliny test-first
• Jak złożyć workflow z /setupTests, Generate Tests, Fix Test Failure i agenta implementacyjnego
• Jak utrzymać pętlę red-green-refactor przy pracy z AI

AI bardzo łatwo rozbija TDD, jeśli oddasz mu zbyt dużo naraz

To główne ryzyko.

Jeśli po prostu poprosisz agenta: “zrób feature i dopisz testy”, bardzo często skończysz z klasycznym test-last workflow w ładniejszym opakowaniu.

TDD z Copilotem działa dopiero wtedy, gdy pilnujesz kolejności.

Red: zacznij od testu albo od ram testów

VS Code daje kilka wejść do tego kroku:

• /setupTests, jeśli projekt nie ma jeszcze sensownej konfiguracji testów
• Generate Tests z edytora
• prompt w Chat albo Inline Chat do wygenerowania testów i edge case’ów

Najważniejsze jest jednak to, żeby test opisywał oczekiwane zachowanie zanim agent zacznie implementować.

To właśnie zabezpiecza Cię przed halucynowaniem wymagań przez model.

Green: implementacja minimalna, nie “pełne rozwiązanie od razu”

To punkt, w którym trzeba być twardym operatorem.

Po wygenerowaniu testu nie prosisz agenta o maksymalnie elegancką architekturę. Prosisz o minimalną implementację potrzebną do przejścia testu.

W guide’zie context engineering pojawia się nawet wzorzec TDD implementation agenta, który wprost wymusza:

• test first
• minimalną implementację
• natychmiastowe uruchamianie testów
• pełną walidację przed przejściem dalej

To bardzo dobry kierunek myślenia.

Refactor: AI jest tu naprawdę przydatne

Refaktoryzacja to obszar, w którym Copilot bardzo często daje realną wartość.

Masz już zielone testy, więc możesz użyć AI do:

• uproszczenia implementacji
• poprawy nazw
• wydzielenia funkcji
• wyrównania stylu do wzorców projektu

Warunek jest jeden: testy muszą zostać zielone po każdym kroku.

Fix Test Failure domyka pętlę feedbacku

Docs o testowaniu podkreślają dobrą rzecz: jeśli test padł, masz gotową ścieżkę diagnostyczną przez Fix Test Failure albo przez agenta, który analizuje output testów.

To bardzo praktyczne, bo skraca drogę między objawem a poprawką. Ale znowu: nie chodzi o to, żeby AI “naprawiło wszystko”. Chodzi o to, żeby pomogło utrzymać pętlę TDD w ruchu.

Najlepiej działa drobny batch pracy

TDD z AI psuje się, gdy batch jest zbyt duży.

Jeśli próbujesz w jednym kroku:

• napisać pięć testów
• wdrożyć całą funkcję
• zrobić refactor
• odpalić cały pakiet testów

to bardzo szybko tracisz kontrolę nad przyczyną błędu.

Znacznie lepiej działa rytm:

1. Jeden test albo mały pakiet testów.
2. Minimalna implementacja.
3. Uruchomienie testu.
4. Krótki refactor.

Instructions dla testów też mają znaczenie

Docs o testowaniu mówią wprost, że możesz personalizować generowanie testów przez custom instructions.

To świetne miejsce na zapisanie:

• preferowanego frameworka
• konwencji nazewniczych
• oczekiwanego stylu testów
• rodzaju coverage i edge case’ów

Dzięki temu TDD z AI staje się powtarzalnym workflow, a nie serią przypadkowych promptów.

TDD z agentem ma sens dopiero z planem i granicami

Jeśli używasz agenta do większego zadania, dobrze połączyć to z planem albo promptem implementacyjnym opartym na planie.

Wtedy agent nie “tworzy rozwiązania od zera”, tylko realizuje ustalone kroki i weryfikuje je testami.

To jest dużo bliższe prawdziwej pracy inżynierskiej niż spontaniczne generowanie całej funkcji.

Ćwiczenie praktyczne

Weź małą funkcję albo endpoint i przeprowadź dla niego pełną pętlę red-green-refactor:

1. Wygeneruj albo napisz test opisujący oczekiwane zachowanie.
2. Poproś Copilota tylko o minimalną implementację.
3. Uruchom test i popraw porażkę przez Fix Test Failure albo analizę outputu.
4. Zrób refactor bez zmiany zachowania.

Na końcu oceń, w którym kroku AI było najbardziej pomocne, a w którym wymagało najwięcej dyscypliny z Twojej strony.

Kluczowe wnioski

• TDD z Copilotem działa tylko wtedy, gdy pilnujesz kolejności red-green-refactor.
• AI świetnie wspiera generowanie testów, interpretację porażek i refaktoryzację.
• Największym ryzykiem jest zbyt duży batch pracy i powrót do test-last workflow.
• Custom instructions i plan pomagają utrzymać powtarzalność całego procesu.

Co dalej

Masz już workflow planowania, kontekstu i testów. Następny krok to debugowanie: jak używać AI do diagnozowania problemów i jak debugować samą sesję AI, gdy model albo toolchain zachowują się podejrzanie.