AI mówi „testy przeszły”. Sprawdź, czy miały szansę znaleźć błąd

„Dwanaście testów, wszystkie przeszły”. Raport asystenta kodującego wygląda uspokajająco, zwłaszcza po godzinie rozmowy o poprawce. Zanim zamkniesz zadanie, przyda się jedno dalsze pytanie: który z tych testów przestałby przechodzić, gdyby poprawka była błędna?

Nazwa przypadku, sprawdzana odpowiedź i wynik uruchomienia pozwalają odróżnić dowód dotyczący konkretnego zachowania od informacji, że wykonano jakieś polecenie. Przy pracy z AI te dwie rzeczy łatwo sklejają się w krótkie „gotowe”. Potem gotowe okazuje się bardzo pojemnym słowem.

Raport zaczyna się od tego, co naprawdę uruchomiono

Poproś o dokładne polecenie, miejsce jego wykonania i wynik narzędzia. Nazwa skryptu nie wystarcza. W jednym projekcie polecenie test może uruchamiać właściwy zestaw, w innym sprawdzać jedynie formatowanie albo wyświetlać komunikat pomocniczy. Odbiorca powinien móc ustalić zakres bez odgadywania zamiarów osoby, która nadała nazwę.

Sprawdź liczbę zebranych, wykonanych, pominiętych i nieudanych testów. Sam koniec procesu nie mówi, czy znalazł się w nim przypadek dotyczący poprawki. Jeśli raport zawiera dwanaście pozycji, powinno dać się wskazać tę, która sprawdza nowe zachowanie. Licznik zbiorczy może pozostać taki sam mimo uruchomienia zupełnie innego katalogu.

Dokumentacja kodów zakończenia pytest przypisuje kod 0 do pomyślnie zebranych i zaliczonych testów, a kod 5 do braku zebranych testów. To rozróżnienie konkretnego narzędzia. Zielony wynik skryptu opakowującego nie zastępuje informacji, co zwrócił sam pytest i jakie testy znalazł.

W raporcie odróżnij wykonanie od planu wykonania. Asystent może napisać poprawną komendę, której nie uruchomił, albo opisać test, którego plik dopiero proponuje dodać. Obie informacje mogą być użyteczne, lecz żadna nie potwierdza wyniku. Jeśli środowisko zablokowało uruchomienie, zachowaj tę granicę w końcowej odpowiedzi.

Przy długim logu zachowaj końcowy wynik i pełny zapis potrzebny do odczytu zakresu. Ucięta odpowiedź narzędzia może zawierać pierwsze pozytywne pozycje, a pomijać późniejsze niepowodzenie. Asystent powinien doczytać zakończenie procesu, zanim podsumuje test jako udany. Sam fakt, że polecenie nadal działa, również nie jest wynikiem pozytywnym; oznacza oczekiwanie na rozstrzygnięcie.

Ustal także, na jakiej wersji pracowano. Test sprzed ostatniej zmiany nie zatwierdza automatycznie pliku po tej zmianie. Zapisana wersja kodu, wersja testu i log wykonania powinny tworzyć jeden rozpoznawalny zestaw. Przy lokalnych zmianach możesz zachować dokładną kopię ocenianych plików; oznaczenie wcześniej zapisanej wersji nie musi obejmować bieżących zmian lokalnych.

Jeśli test uruchamia inny program lub usługę, sprawdź, co stanowi jego wynik. Komunikat „wysłano żądanie” może być dopiero początkiem działania. Przy ocenie środowiska testowego automatyzacji AI trzeba powiązać uruchomienie z obserwowanym skutkiem. W testach kodu obowiązuje ten sam porządek: wykonanie czynności i sprawdzenie jej wyniku są osobnymi elementami.

Asercja ma rozpoznać właściwy rezultat

Asercja to sprawdzenie, czy zaobserwowany wynik zgadza się z oczekiwaniem. W naszym hipotetycznym systemie zapisu pracownia ma limit sześciu uczestników. Zadanie dla asystenta brzmi: pozwól zapisać sześć osób, odmów przy siedmiu. Test powinien rozróżniać te sytuacje zgodnie z zasadą ustaloną dla warsztatu.

Wywołanie funkcji bez sprawdzenia odpowiedzi może wykryć jej awarię, ale nie musi wykryć złej decyzji. Program może grzecznie zwrócić zgodę na dowolną liczbę miejsc. Test nadal zakończy się spokojnie, jeśli oczekiwał wyłącznie braku błędu wykonania. Dlatego zapisz, co oznacza sukces: przyjęcie sześciu oraz odmowa dla siedmiu, a nie samo wywołanie funkcji.

Oczekiwania nie powinien ustalać ten sam fragment programu, który jest sprawdzany. Jeżeli test pyta implementację o poprawną odpowiedź, po czym porównuje ją z tą samą odpowiedzią, może jedynie potwierdzić jej zgodność z samą sobą. Zasada „sześć dozwolone, siedem odrzucone” powinna pochodzić z wymagania i być widoczna w przypadku kontrolnym.

Jeśli asystent zmienił również test, przejrzyj różnicę w oczekiwaniu. Zmiana „odmów przy siedmiu” na „przyjmij siedem” może sprawić, że błędny kod przejdzie wszystkie próby. Bywa też uzasadniona zmianą wymagania, lecz wtedy trzeba tę decyzję nazwać i zatwierdzić osobno. Zielony wynik po jednoczesnej zmianie programu i kryterium nie pozwala sam ustalić, co właściwie naprawiono.

Przy poprawce zgłoszonej usterki poproś o przypadek odtwarzający jej konkretny objaw. Jeśli można go uruchomić na wersji sprzed poprawki, powinien wskazać tam niezgodność z wymaganiem, a po naprawie przejść. Nie jest to obowiązek budowania wielkiej historii testów dla każdej kosmetycznej zmiany. Pomaga jednak sprawdzić, czy dodany test w ogóle dotyczy problemu, który miał zostać usunięty.

Sprawdź, czy użyte dane umożliwiają odróżnienie wersji poprawnej od błędnej. Próba z dwiema osobami nie ujawni zamiany „najwyżej sześć” na „mniej niż sześć”. Do obu wersji dwie osoby pasują. Przypadek dokładnie na granicy sprawdza właśnie to rozróżnienie, bez potrzeby uruchamiania stu losowych liczb.

Nie wszystkie wymagania są jednak regułą liczbową. Jeśli poprawka dotyczy komunikatu po odmowie, właściwy test może sprawdzać pokazanie przyczyny i zachowanie wpisanych danych. Jeżeli dotyczy zapisu, potrzebna może być kontrola, czy dane rzeczywiście można później odczytać. Dobierz dowód do zachowania, które odbierasz, zamiast wymagać wszędzie tej samej formy testu.

Przy zewnętrznej usłudze test bywa oparty na atrapie, czyli kontrolowanym zastępstwie prawdziwego połączenia. Pozwala to sprawdzić wybrane reakcje programu. Nie dowodzi działania rzeczywistej usługi. Jeśli atrapa zawsze odpowiada sukcesem, brak odpowiedzi albo odmowa pozostaną poza zakresem tej próby. Raport powinien nazwać, którą część sprawdzono w zastępstwie.

Obejrzyj obsługę błędów w samym teście. Jeżeli przechwytuje każdy błąd i kończy bez sprawdzenia, próba może zgłosić sukces również wtedy, gdy badana funkcja w ogóle nie zwróciła odpowiedzi. Odróżnij oczekiwaną odmowę zapisu od awarii połączenia i od błędu przygotowania testu. Wszystkie mogą przerwać zwykłą drogę wykonania, lecz dowodzą czego innego.

Oceń też, czy test nie pomija pytania przez zbyt ogólne oczekiwanie. „Odpowiedź istnieje” nie rozstrzyga, czy zawiera odmowę dla siedmiu osób. „Zwrócono listę” nie potwierdza właściwych uczestników. Asystent może przygotować składniowo poprawną asercję, która sprawdza cechę zbyt słabą wobec deklarowanego celu.

Kontrolowana usterka pokazuje czułość testu

W opisie testów mutacyjnych Strykera autorzy przedstawiają zasadę celowej zmiany kodu i ponownego uruchomienia testów. Oczekiwane niepowodzenie testu pokazuje wykrycie danej zmiany. Taki sposób myślenia pomaga sprawdzić siłę konkretnej próby, nawet gdy nie uruchamiasz pełnego narzędzia do mutacji.

Samo pokrycie kodu, czyli informacja, które fragmenty zostały wykonane podczas testów, nie odpowiada jeszcze na pytanie o poprawność ich rezultatu. Autorzy Strykera zwracają uwagę na tę różnicę. Przy odbiorze naszej poprawki wskaż więc badaną regułę i sprawdź wynik, który powinien się zmienić po jej uszkodzeniu.

W kopii przykładu z pracownią można celowo zmienić warunek tak, aby sześć osób zostało odrzuconych. Wcześniej wybrany test graniczny powinien teraz zgłosić niepowodzenie dotyczące tego zachowania. Jeśli nadal przechodzi, ustal, czy uruchomiono właściwy test i czy rzeczywiście korzystał ze zmienionej funkcji.

Zmieniaj jeden element naraz i opisz oczekiwany sygnał. Jeśli uszkodzisz cały plik tak, że nie da się go wczytać, dowiesz się głównie o wykrywaniu błędu wczytania. To inny dowód niż rozpoznanie błędnej decyzji o liczbie miejsc. Usterka ma być wystarczająco precyzyjna, aby wynik odpowiadał na pytanie o testowaną regułę.

Przeprowadź tę próbę na odizolowanej kopii i przywróć poprawną wersję. Nie trzeba wprowadzać błędów do używanego systemu, żeby ocenić test. Piaskownica agenta AI, czyli środowisko z ograniczonym zakresem działania, wymaga sprawdzenia dostępu do plików i połączeń. Sama nazwa katalogu „testowy” nie ustanawia takiej granicy.

Po przywróceniu kodu uruchom ten sam przypadek jeszcze raz. Otrzymujesz wtedy czytelną sekwencję: poprawna wersja przechodzi, kontrolowana błędna wersja nie przechodzi, przywrócona znowu przechodzi. Zapisz wyniki wraz z różnicą w pliku. Nie przedstawiaj takiej sekwencji jako wykonanej, jeśli w rzeczywistości tylko opisano, jak mogłaby wyglądać.

Dobierz zakres celowych usterek do znaczenia zmiany. Wybierz reguły, przy których ma to znaczenie: granicę liczby miejsc, pominięcie danych albo błędne uznanie odmowy za sukces. Celem jest odpowiedź na konkretne pytanie odbioru, a nie imponująca liczba dodatkowych uruchomień.

Testy mogą przejść obok zmienionego kodu

Gdy celowa usterka nie zmienia wyniku, nie poprawiaj od razu oczekiwanej odpowiedzi. Najpierw sprawdź drogę wykonania. Test mógł wczytać inną kopię pliku, gotowy wcześniej pakiet albo atrapę zastępującą funkcję. W takim przypadku dokładanie kolejnych danych do tego samego testu nie sprawdzi kodu, do którego w ogóle nie dociera.

Poproś o wskazanie pliku i funkcji, które zostały użyte. Przy kilku podobnych katalogach sama nazwa funkcji może nie wystarczyć. Jeżeli przed testem potrzebne jest przygotowanie aplikacji, sprawdź, czy je wykonano po poprawce. Dowód powinien łączyć bieżący plik z uruchomioną wersją, a nie tylko sąsiedztwo ich nazw w raporcie.

Znaczenie mają też wyłączenia. Jeśli asystent nie miał dostępu do części plików, jego sprawdzenie może obejmować tylko widoczny fragment. Osobno oceń, czy ograniczenie było skuteczne, a osobno, jaki zakres testów dało się wtedy wykonać. Te kwestie rozwija tekst o wyłączonych plikach a rzeczywistym dostępie asystenta kodu.

Przy wyniku niestabilnym zachowaj także wcześniejsze niepowodzenia. Jeżeli ten sam przypadek raz przechodzi, a raz nie, pojedyncza udana próba nie wyjaśnia przyczyny. Sprawdź zależność od bieżącej godziny, kolejności uruchamiania lub danych pozostawionych przez poprzedni test. Po usunięciu rozpoznanej przyczyny uzgodnij próbę potwierdzającą. Wielokrotne uruchamianie aż do zielonego wyniku samo nie usuwa niepewności.

Nie zaliczaj testu pominiętego do wykonanych pozytywnie. Powód pominięcia może być uzasadniony, na przykład brak dostępu do potrzebnej usługi. Nadal pozostawia pytanie bez sprawdzenia w danym środowisku. W końcowej ocenie zapisz brakujący dowód i sposób jego uzyskania, zamiast przepisywać wszystko do jednej zielonej liczby.

Jeśli uruchomienie zatrzymało się na brakującej bibliotece, najpierw ustal pochodzenie zależności. Kontrola pakietów proponowanych przez AI dotyczy innego problemu niż siła asercji. Dodanie przypadkowego pakietu wyłącznie po to, żeby usunąć czerwony komunikat, nie rozstrzyga żadnego z tych pytań.

Końcowy raport ma pozwolić przyjąć konkretną zmianę

Zamiast „wszystko działa” zapisz, jakie zachowanie sprawdzono, w jakiej wersji i z jakim wynikiem. W naszym przykładzie raport może wskazać przyjęcie sześciu osób, odmowę dla siedmiu oraz przejście próby po przywróceniu poprawnego warunku. Jeśli kontrolowanej usterki nie wykonano, opisz wyłącznie rzeczywiście przeprowadzone sprawdzenia.

Odbiór kodu i pracy agentów AI powinien łączyć takie dowody z odpowiedzialnością za dalsze użycie. Osoba przyjmująca zmianę potrzebuje znać pozostałe granice: atrapy, niedostępne usługi, pominięte przypadki i zakres przeglądu. Nie musi dostawać historii każdej nieudanej komendy, jeśli nie wyjaśnia ona obecnego wyniku.

W Aeneia Audit można ocenić sposób wykorzystywania AI, kryteria przyjęcia i jakość raportowanych dowodów. Specjalistyczny przegląd samego kodu wymaga odpowiednich kompetencji i uzgodnionego zakresu. W tym odbiorze chodzi o to, żeby deklaracja asystenta dawała się powiązać z konkretną wykonaną próbą i jej znaczeniem.

Po takim raporcie „dwanaście testów” może pozostać przydatnym skrótem. Za nim powinny jednak stać przypadki, które potrafią zakwestionować błędną zmianę. Zielony kolor ma uspokajać dlatego, że coś sprawdzono, a nie dlatego, że dobrze wygląda obok słowa „gotowe”.