Developer · FREE

Refaktor za testami charakteryzacji

Zanim ruszy legacy, spina obecne zachowanie testami charakteryzacji, dopiero potem czyści. Po refaktorze te same testy muszą przejść. Zero przepisywania na nowy stack przy okazji.

reviewed:

Jak zainstalować

  1. Uzupełnij pola poniżej (albo zostaw nazwy zmiennych i dopisz w czacie). Wartości z Skill creatora na liście podstawiają się same.
  2. Kopiuj, potem wklej w Claude.ai (instrukcje projektu) albo ChatGPT (Custom Instructions).
  3. Albo pobierz SKILL.md i połóż w folderze skilli Claude Code.
SKILL
Plik albo moduł: [MODUL]. Co ma zostać prawdą (objaw / kontrakt publiczny): [ZACHOWANIE]. Komenda testów: [TESTY].

To NIE jest nowe zachowanie. Sąsiad `testy-zachowania` pisze failing test na NOWE Y i stop. Tu siatka na STARE Y, potem kształt kodu, Y bez zmian.

Jeśli [TESTY] puste albo nie umiesz odpalić runnera - stop, nie zgaduj.
Jeśli [ZACHOWANIE] brzmi jak nowa funkcja ("ma też wysyłać mail") - to feature; odeślij do testy-zachowania / tdd-czerwony-zielony i stop.

Faza A (obowiązkowa, zanim ruszysz produkcję):

1. Wypisz publiczny kontrakt: wejście -> wyjście / status / wyjątek, który DZIŚ zachodzi (nie ten, który "powinien").
2. Napisz zestaw testów charakteryzacji (golden master): konkretne wejścia, konkretne wyjścia. Mockuj tylko I/O.
3. ODPAL [TESTY]. Wklej output. Testy MUSZĄ być zielone na STARYM kodzie. Jeśli czerwone - test kłamie, popraw test, nie produkcję.
4. Stop. Pokaż listę asercji. Nie refaktoryzuj w tej samej turze, dopóki człowiek nie powie "ok, czyść".

Faza B (po "ok, czyść"):

- plan 3-6 commitów: każdy to jeden ruch (wyciągnij funkcję, zmień nazwę, przesuń plik, usuń duplikat)
- publiczny kontrakt bez zmian: sygnatury, statusy HTTP, JSON, kolejność side-effectów, które testuje siatka
- po KAŻDYM commicie ta sama komenda [TESTY]; wklej wynik
- jeśli czerwono: revert commita, nie "dopiszę asercję, bo teraz inaczej"
- zero "przy okazji": nowy stack, nowa biblioteka, zmiana zachowania, formatowanie całego repo

Artefakt, który zwracasz:

1. Tabela charakteryzacji: wejście | obecne wyjście | test
2. Output zielonej komendy z fazy A
3. Plan commitów (3-6)
4. Po zgodzie: diff bez zmiany kontraktu + output tej samej komendy po każdym commicie

Zakaz zgłaszać "done", gdy siatka nie jest zielona albo gdy zmieniłeś Y. Dywiz "-". Kod po angielsku.

Zanim wkleisz

Skill vs zły prompt Użyj z tym narzędziem

Skill vs zły prompt

Zły prompt

Przepisz ten moduł na nowy stack i przy okazji popraw zachowanie, testy potem.

Skill

Plik albo moduł: [MODUL]. Co ma zostać prawdą (objaw / kontrakt publiczny): [ZACHOWANIE]. Komenda testów: [TESTY].

To NIE jest nowe zachowanie. Sąsiad `testy-zachowania` pisze failing test na NOWE Y i stop. Tu siatka na STARE Y, potem kształt kodu, Y bez zmian.

Jeśli [TESTY] puste albo nie umiesz odpalić runnera - stop, nie zgaduj.
Jeśli [ZACHOWANIE] brzmi jak nowa funkcja ("ma też wysyłać mail") - to feature; odeślij do testy-zachowania / tdd-czerwony-zielony i stop.

Faza A (obowiązkowa, zanim ruszysz produkcję):

Użyj z tym narzędziem

Lekcja: claude-start-06-claude-dla-programisty

Pytania

Jak użyć skilla "Refaktor za testami charakteryzacji" w Claude?

Uzupełnij pola w nawiasach (albo weź je z profilu Skill creator na /skille), kliknij Kopiuj i wklej treść do instrukcji projektu w Claude.ai. W Claude Code kliknij Pobierz SKILL.md i połóż plik w folderze skilli. Skill działa też w ChatGPT (Custom Instructions). Nie chowa się za paywallem: kopia jest darmowa.

Kiedy tego skilla NIE używać?

Nie gdy zachowanie ma się zmienić (to feature, nie refaktor). Nie do wielkiego przepisania od zera bez bramki. Nie gdy nie ma jak odpalić kodu.