Generowanie testów i dokumentacji przez Smart Actions

Czego się nauczysz

• Jak traktować Generate Tests i Generate Docs jako bootstrap, a nie gotowy artefakt końcowy
• Kiedy smart action wystarczy, a kiedy trzeba wejść w doprecyzowanie przez Inline Chat albo slash commands
• Jak reviewować wygenerowane testy i dokumentację, żeby nie produkować wiarygodnie brzmiącego szumu

To są jedne z najbardziej praktycznych smart actions w całym VS Code

W codziennej pracy często nie potrzebujesz genialnego promptu. Potrzebujesz dobrego startu.

I właśnie dlatego generowanie testów oraz dokumentacji przez smart actions jest tak użyteczne. To dwa zadania, które regularnie odkładamy, bo są potrzebne, ale rzadko są najbardziej ekscytującym fragmentem pracy.

VS Code pozwala zacząć je jednym kliknięciem z poziomu edytora.

Generate Tests daje bootstrap, nie gwarancję jakości

Dokumentacja opisuje workflow bardzo prosto:

1. Otwierasz plik z kodem.
2. Opcjonalnie zaznaczasz fragment.
3. Wybierasz Generate Code > Generate Tests.

VS Code może wygenerować testy w istniejącym pliku testowym albo utworzyć nowy, jeśli go jeszcze nie ma.

To jest świetny skrót, bo najtrudniejszy psychologicznie bywa pierwszy krok:

• wybrać framework i styl
• napisać pierwszy przypadek testowy
• zbudować strukturę pliku

Smart action bardzo dobrze usuwa właśnie ten koszt wejścia.

Ale tu trzeba być brutalnie praktycznym: wygenerowane testy są draftem. Mogą być przydatne, poprawne składniowo, a jednocześnie słabe z perspektywy pokrycia ryzyk.

Najczęstsze problemy są trzy:

• testują tylko happy path
• powielają implementację zamiast sprawdzać zachowanie
• są zbyt ciasno związane z detalami, które zaraz się zmienią

Dlatego pytanie po wygenerowaniu testów powinno brzmieć: czego tu nadal brakuje?

Generate Docs oszczędza czas, ale nie zna odbiorcy lepiej od Ciebie

Podobnie działa Generate Docs. Zaznaczasz kod albo pracujesz na bieżącym pliku i prosisz VS Code o wygenerowanie dokumentacji.

To przydaje się szczególnie wtedy, gdy chcesz szybko uzupełnić:

• komentarze do publicznych metod
• opis parametrów i zwracanej wartości
• krótkie objaśnienie bardziej złożonego fragmentu API

Tutaj również warto pamiętać, że AI zwykle wie, jak zbudować poprawny format komentarza, ale nie wie automatycznie, dla kogo ta dokumentacja jest pisana.

Inaczej piszesz komentarz do:

• publicznej biblioteki
• wewnętrznego helpera zespołu
• krytycznego modułu domenowego

Jeżeli nie doprecyzujesz oczekiwań, model wygeneruje coś generycznego. Technicznie poprawnego, ale mało wartościowego.

Smart action to punkt startu, refinowanie robisz dalej

Duża zaleta tego workflow polega na tym, że po wygenerowaniu testów albo docs możesz dalej iterować w Inline Chat.

To znaczy, że nie musisz od razu otwierać osobnej sesji i budować wszystkiego od zera. Zaczynasz od gotowej akcji, a potem doprecyzowujesz wynik.

Przykłady sensownych follow-upów:

• dodaj edge case’y dla pustego inputu
• przepisz testy na styl używany w tym repo
• skróć komentarz i skup się na kontrakcie publicznego API
• dopisz przykład użycia

To bardzo ważny wzorzec: smart action uruchamia intencję, a chat refinuję wynik.

Kiedy lepsze będzie /tests albo /doc

Cheat sheet przypomina, że obok smart actions masz też slash commands jak /tests i /doc.

Różnica jest praktyczna:

• smart action wygrywa, gdy jesteś już na właściwym fragmencie kodu i chcesz wystartować natychmiast
• slash command wygrywa, gdy chcesz dodać więcej instrukcji albo pracować w rozmowie

Na przykład samo Generate Tests jest świetne do pierwszego draftu. Ale gdy chcesz od razu wymusić konkretny framework, zakres edge case’ów i uruchomienie testów, chat albo agent da większą kontrolę.

Zamknięcie pętli: wygenerować to za mało

W dokumentacji smart actions obok generowania testów pojawia się też Fix Test Failure. To nie jest przypadek.

Dobry workflow nie kończy się na wygenerowaniu pliku. Kończy się dopiero wtedy, gdy:

• testy mają sens
• przechodzą albo jasno pokazują realny problem
• dokumentacja odpowiada na pytania odbiorcy

To jest właśnie różnica między “AI coś dopisało” a “AI pomogło domknąć zadanie”.

Ćwiczenie praktyczne

Wybierz jedną funkcję albo klasę w swoim projekcie i wykonaj dwa kroki:

1. Wygeneruj dla niej testy przez smart action.
2. Wygeneruj dokumentację dla tego samego fragmentu kodu.

Potem doprecyzuj wynik jednym follow-upem, na przykład:

• dodaj brakujące edge case’y
• uprość komentarz
• dopasuj styl do repo

Na końcu oceń:

• co smart action zrobiło dobrze od ręki
• co wymagało dopowiedzenia
• czy po tej iteracji wynik faktycznie nadaje się do utrzymania w repo

Kluczowe wnioski

• Generate Tests i Generate Docs świetnie usuwają koszt wejścia w nudniejsze, ale ważne zadania.
• Wygenerowany wynik jest zwykle draftem i wymaga review człowieka.
• Najczęstszy brak w testach to edge case’y, a w dokumentacji brak dopasowania do odbiorcy i stylu zespołu.
• Smart action najlepiej traktować jako bootstrap, a Inline Chat albo slash commands jako warstwę refinowania.
• Dobra automatyzacja nie kończy się na wygenerowaniu pliku, tylko na sensownym domknięciu całego zadania.

Co dalej

Masz już komplet smart actions, więc możemy wejść poziom wyżej: wieloplikowe zmiany, planowanie, review edits i checkpoints w pracy agentowej.