92% na domowym teście, 36% na obcym: ile naprawdę zmienia agent od testów

Najcichszy sposób, w jaki test potrafi zawieść, wygląda tak: kompiluje się, przechodzi u ciebie na maszynie i nigdy nie rusza w CI, bo nikt nie wpiął go w komendę, która testy uruchamia. Microsoft twierdzi, że jego agent do pisania testów jednostkowych, code-testing-generator, pilnuje dokładnie tego przypadku. Pisałem o nim tydzień temu, gdy firma wypuściła go na licencji MIT. Wracam, bo doszły dwie rzeczy, których wtedy nie było: niezależny test i głos z zewnątrz, który dość celnie nazywa, co to narzędzie naprawdę zmienia, a czego nie.

Sam pomysł jest prosty. Zamiast generować testy prosto z jednego polecenia, agent najpierw czyta repozytorium: wykrywa język, znajduje framework testowy, podgląda istniejące testy, żeby złapać konwencje projektu, i ustala prawdziwe komendy budowania oraz uruchamiania. Skalę pracy dobiera do zadania, bo pojedynczą metodę bierze od razu, a pokrycie całego podsystemu rozkłada na powtarzane rundy, aż dobije do wyznaczonego celu. Dopiero potem pisze testy, odpala je i sprawdza to, co napisał. Nie dotyka kodu produkcyjnego i omija testy, które biją do sieci, otwierają porty albo zależą od zegara, czyli te, które później losowo się wywalają.

Całe to rozeznanie nie jest ozdobą. Gołe polecenie "napisz testy" nie mówi, którego frameworka użyć, gdzie położyć pliki ani jakich asercji się trzymać, więc klasyczny asystent po prostu zgaduje, a jego testy często nie kompilują się albo nie przechodzą, dopóki ktoś ich ręcznie nie posprząta. Agent, który najpierw pozna projekt, wpasowuje się w istniejący kod, zamiast produkować ogólne przykłady oderwane od reszty.