Czy AI może pisać przypadki testowe z kodu źródłowego? Co działa w praktyce

Tak — AI potrafi dziś przeczytać repozytorium i napisać do niego przypadki testowe, a część narzędzi także uruchamia je według harmonogramu. Ale „AI pisze testy” obejmuje trzy różne rzeczy: generowanie testów jednostkowych z kodu, sprawdzanie scenariuszy end-to-end na działającej aplikacji i platformy, które łączą jedno i drugie z wykonywaniem pipeline Pipeline to ustalona z góry sekwencja kroków przetwarzania — w odróżnieniu od agenta nie wybiera kolejności, tylko zawsze wykonuje tę samą. Pełna definicja →'ów. W praktyce dobrze działa pierwszy szkic testów dla plików, które testów nie mają: dopasowany do konwencji projektu, skompilowany, zlintowany i oddany człowiekowi do przeglądu w pull requeście. Słabo działa zaufanie bez uruchomienia. Poniżej opisujemy, jak robi to nasz Testing AI Assistant, gdzie generowanie testów z kodu zawodzi i czym to podejście różni się od narzędzi, które najczęściej wymieniają asystenci AI.

Krótka odpowiedź: tak, ale „AI pisze testy” znaczy trzy różne rzeczy

Pierwsza grupa to generatory testów jednostkowych. Biorą klasę lub funkcję i tworzą test, który ją wywołuje i sprawdza wynik. Starsze narzędzia z tej grupy, jak EvoSuite dla Javy, przeszukują przestrzeń możliwych wejść algorytmicznie; nowsze używają modeli językowych albo uczenia ze wzmocnieniem. Ich mocną stroną jest skala: potrafią szybko objąć testami dużo kodu. Słabą — oczekiwania wyprowadzają z tego, co kod robi teraz, a nie z tego, co powinien robić.

Druga grupa to agenci end-to-end. Zaczynają od działającej aplikacji, czasem od opisu wymagań, i sprawdzają scenariusze z perspektywy użytkownika: logowanie, koszyk, formularz. Kod źródłowy jest dla nich kontekstem, a nie głównym wejściem.

Trzecia grupa to platformy orkiestracji Orkiestracja to koordynowanie wielu modeli, narzędzi i agentów tak, by pracowały nad jednym zadaniem w ustalonej kolejności i przekazywały sobie wyniki. Pełna definicja →: generują testy, ale przede wszystkim pilnują, żeby testy były regularnie uruchamiane, a wyniki trafiały do zespołu. Testing AI należy do tej trzeciej grupy i ma w środku dwa generatory: testów z kodu i scenariuszy E2E. Pytanie „czy AI napisze testy z mojego kodu” warto więc doprecyzować: jakie testy, na jakim wejściu i kto je potem uruchamia.

Jak Testing AI czyta kod źródłowy, zanim cokolwiek napisze

Zaczyna się od dostępu. Organizacja dodaje token Token to fragment tekstu, zwykle kawałek słowa, w którym modele AI mierzą i długość zapytania, i koszt — rachunek wystawiany jest za tokeny, nie za pytania. Pełna definicja → dostawcy — GitHub, GitLab albo Bitbucket — i od tej pory każdy projekt w organizacji może korzystać z kreatora generowania testów. Nikt nie wkleja kodu ręcznie: usługa AI pobiera go przez API API to interfejs, przez który dwa systemy wymieniają dane automatycznie — bez eksportów do Excela i przeklejania ręką. Pełna definicja → dostawcy.

Pierwszy krok to analiza projektu. System pobiera drzewo plików, czyta do 15 plików konfiguracyjnych (package.json, tsconfig.json, konfiguracje Jest, ESLint i podobne) i wyszukuje istniejące pliki testów. Na tej podstawie agent buduje profil projektu: język, framework testowy, menedżer pakietów, katalogi źródłowe, wzorce nazewnictwa testów. Profil jest zapisywany, więc kolejne sesje dla tego samego projektu nie analizują repozytorium od nowa.

Ten krok ma znaczenie, którego nie widać w demo. Test wygenerowany w złym frameworku albo w złym katalogu jest bezużyteczny, nawet jeśli logicznie jest poprawny. Profil sprawia, że propozycje lądują tam, gdzie zespół położyłby je sam: obok istniejących testów, z tym samym schematem nazw.

Od kodu do przypadków testowych: propozycja, akceptacja, generowanie

Na podstawie profilu system wybiera pliki z katalogów źródłowych, pomija te, które już mają testy, pliki deklaracji typów i pliki index, i bierze do 30 plików w obsługiwanych rozszerzeniach (TypeScript, JavaScript, Python, Java, Go, Rust). Można podać obszar, na którym agent ma się skupić, na przykład „moduł autoryzacji”. To dobra praktyka: 30 plików wybranych z całego repozytorium mówi o projekcie mniej niż 30 plików z jednego modułu.

Agent proponuje listę plików testów. Każda pozycja ma plik docelowy, ścieżkę testu zgodną z konwencją projektu, typ testu (jednostkowy, integracyjny lub E2E), opis tego, co test obejmie, uzasadnienie, priorytet i szacowaną liczbę przypadków testowych. Wysoki priorytet dostaje krytyczna logika bez testów, średni — ważny kod częściowo pokryty, niski — rzeczy, które miło mieć.

Tu jest pierwszy punkt kontroli człowieka: nic nie jest generowane, dopóki ktoś nie zatwierdzi pozycji. Można zatwierdzić wszystko albo wybrać kilka.

Generowanie odbywa się plik po pliku, sekwencyjnie. Dla każdego pliku system zbiera kontekst: sam plik docelowy, jego lokalne importy (do 20 plików — typy, interfejsy, funkcje pomocnicze), do trzech istniejących testów projektu jako wzorzec stylu i wyliczone ścieżki importów względnych od pliku testu do plików źródłowych. Potem model pisze test, kod przechodzi czyszczenie (usunięcie formatowania markdown, nieużywanych importów i zmiennych, typowych problemów z typami), a drugi przebieg modelu poprawia ścieżki importów i błędy typów.

flowchart TB
  RE["Repozytorium<br/>GitHub · GitLab · Bitbucket"] --> PR["Profil projektu<br/>język, framework, wzorce testów"]
  PR --> PO["Propozycja<br/>do 30 plików źródłowych"]
  PO --> AP{"Człowiek zatwierdza<br/>pozycje"}
  AP --> GE["Generowanie<br/>plik po pliku"]
  GE --> VA["Walidacja<br/>tsc i ESLint"]
  VA -->|błędy, do 3 prób| GE
  VA --> RV["Przegląd i edycja<br/>w przeglądarce"]
  RV --> CM["Gałąź ai/test-gen<br/>commit i pull request"]
  CM --> CI["Twój CI uruchamia testy"]

Walidacja: „kompiluje się” to nie to samo co „przechodzi”

Po wygenerowaniu wszystkich plików system klonuje repozytorium do katalogu tymczasowego, instaluje zależności (rozpoznaje pnpm, yarn lub npm i instaluje bez skryptów instalacyjnych), kopiuje wygenerowane testy i uruchamia tsc --noEmit oraz ESLint. Jeśli są błędy, wracają do modelu z prośbą o poprawkę, po czym walidacja rusza od nowa — maksymalnie trzy próby. Po trzeciej nieudanej próbie sesja idzie dalej z najlepszym uzyskanym wynikiem, a człowiek widzi, co zostało do poprawienia. Walidację można też pominąć.

Trzeba jasno powiedzieć, czego ta walidacja nie robi: nie uruchamia testów. Sprawdza, że test się kompiluje i spełnia reguły lintera, czyli wyłapuje zmyślone importy, złe typy i nieistniejące funkcje. Nie sprawdza, czy asercje są prawdziwe. Właściwym sprawdzianem jest pierwszy przebieg CI na pull requeście.

Po walidacji wszystkie testy są widoczne w edytorze w przeglądarce. Można je czytać, poprawiać ręcznie i generować ponownie pojedyncze pliki bez ruszania reszty. Commit tworzy od gałęzi domyślnej gałąź ai/test-gen- ze znacznikiem czasu, zapisuje wszystkie pliki w jednym commicie i — jeśli zaznaczono — otwiera pull request z listą wygenerowanych plików. Sesja przetrwa zamknięcie przeglądarki: można do niej wrócić i kontynuować od miejsca, w którym się zatrzymała.

Gdzie generowanie testów z kodu zawodzi

Najczęstszy problem, który opisujemy w dokumentacji produktu, to aliasy ścieżek w monorepo. System liczy importy względne, a projekt używa aliasów w stylu @app/shared z sekcji paths w tsconfig.json. Test jest logicznie poprawny, ale import trzeba poprawić ręcznie w kroku przeglądu.

Drugi problem to halucynacje Halucynacja to odpowiedź AI, która brzmi wiarygodnie, ale jest nieprawdziwa — model uzupełnia lukę domysłem, zamiast przyznać, że nie wie. Pełna definicja → w obiektach pomocniczych. Model czasem wymyśla pole interfejsu albo sygnaturę funkcji, której nie ma, szczególnie w mockach. Drugi przebieg modelu i tsc łapią większość takich przypadków, ale przy złożonych typach coś może się prześlizgnąć.

Trzeci — konfiguracje budowania, których izolowany klon nie odtworzy: własne loadery Webpacka, kroki generowania kodu, zależności wymagające skryptów instalacyjnych. Wtedy walidacja kończy się błędem niezależnie od jakości testu i pozostaje ją pominąć, a poprawki zrobić po commicie.

Czwarty problem jest wspólny dla wszystkich generatorów, które wyprowadzają oczekiwania z kodu: jeśli funkcja ma błąd, wygenerowany test może go utrwalić, sprawdzając obecne, błędne zachowanie. Generator nie zna intencji autora. Dlatego wygenerowane testy dobrze sprawdzają się jako siatka bezpieczeństwa przed refaktorem i jako start dla kodu bez testów, a gorzej jako dowód, że kod działa poprawnie.

Piąty to zasięg. Najlepsze wyniki daje TypeScript i JavaScript z Jest lub Vitest, bo dla nich działa najbardziej rozbudowane rozwiązywanie importów i walidacja przez tsc i ESLint. Kreator był testowany także z Mocha i Playwright, z pytest, JUnit, standardowym pakietem testing w Go i cargo test w Ruście, ale tam etap walidacji sprawdza mniej.

Do tego dochodzą czas i koszt. Każdy plik to dwa–trzy wywołania modelu. Według naszej dokumentacji dla dziesięciu zatwierdzonych pozycji trzeba liczyć 3–5 minut, a typowa sesja na pięć plików zużywa w przybliżeniu 30–60 tysięcy tokenów, zależnie od złożoności kodu. Zużycie tokenów jest widoczne w szczegółach sesji.

Testy E2E z opisu: listy kontrolne i Playwright

Nie każdy test da się sensownie wyprowadzić z kodu. Scenariusz „użytkownik rejestruje się z zajętym adresem e-mail” lepiej opisać słowami i sprawdzić na działającej aplikacji. Do tego służy druga ścieżka w Testing AI.

Agent generuje listę kontrolną z adresu aplikacji, adresu repozytorium albo opisu: od 10 do 25 scenariuszy, każdy z tytułem, opisem, oczekiwanym zachowaniem i priorytetem. Lista przechodzi własną walidację i do dwóch rund poprawek. Z każdej pozycji można wygenerować test Playwright z dostępnymi selektorami. Recenzent oparty na szybszym modelu sprawdza składnię, użycie API Playwright, importy, brak zakodowanych na sztywno adresów i sensowne asercje, z maksymalnie trzema rundami poprawek.

Uruchomienie listy kontrolnej wykonuje test każdej pozycji po kolei na wskazanym adresie aplikacji. Wynik każdej pozycji — status, czas, log i zrzuty ekranu — pojawia się na bieżąco. Listy można eksportować i importować jako JSON, więc da się je trzymać w repozytorium obok kodu.

Jak wyglądają uruchomienia: pipeline, Temporal, równoległość

Wygenerowanie testów to połowa pracy; drugą jest regularne uruchamianie. W Testing AI pipeline to lista kroków, a każde uruchomienie to przepływ w Temporal. Najpierw repozytorium jest klonowane na wskazanym commicie. Potem testy jednostkowe, integracyjne, lint, SAST i audyt zależności idą równolegle, a E2E (w tym Playwright), testy obciążeniowe (w tym k6), DAST i pomiar pokrycia — sekwencyjnie po nich. Testy E2E są pomijane, jeśli testy jednostkowe nie przeszły: nie ma sensu klikać po aplikacji, której logika już nie działa.

Każda aktywność ma własny limit czasu i politykę ponowień w Temporal, więc chwilowy błąd sieci przy klonowaniu nie kończy całego uruchomienia, a awaria jednego kroku nie przerywa pozostałych. SAST używa Semgrep, gdy jest dostępny, DAST — OWASP ZAP, audyt zależności — npm, yarn lub pnpm audit, pip-audit albo govulncheck, zależnie od projektu. Postęp kroków trafia do dashboardu na żywo przez Server-Sent Events, a zrzuty ekranu, nagrania i raporty pokrycia — do magazynu artefaktów.

Uruchomienia według harmonogramu: stan na dziś

Pytanie z wyszukiwarki brzmi zwykle „generuje testy i planuje uruchomienia”, więc odpowiadamy wprost. W modelu pipeline'u są cztery wyzwalacze: push, pull request, harmonogram z wyrażeniem cron i uruchomienie ręczne. Webhooki z GitHub, GitLab i Bitbucket są przyjmowane i weryfikowane podpisem. W obecnej wersji automatyczne startowanie uruchomień z wyrażenia cron i z webhooków nie jest jednak jeszcze podłączone: konfigurację da się zapisać, ale uruchomienie startuje z dashboardu, przez API (POST /test-runs) albo z czatu, który ma narzędzie do uruchamiania pipeline'u.

Jeśli potrzebujesz nocnych przebiegów już teraz, najprostsza droga to zaplanowane zadanie w Twoim CI, które wywołuje to API. Sam przebieg, raportowanie i analiza wyników działają tak samo bez względu na to, co go uruchomiło.

Co dzieje się po uruchomieniu: niestabilne testy, błędy, pokrycie

Tu do gry wracają agenci. Wykrywanie niestabilnych testów bierze 10 ostatnich zakończonych uruchomień projektu, szuka testów, które raz przechodzą, a raz nie, nadaje im wskaźnik niestabilności i wzorzec (zależność od czasu, od kolejności, od środowiska, wyścig) i proponuje poprawki. Wykrywanie błędów zestawia ostatni diff i pliki z repozytorium z wynikami testów i zwraca raport z poziomem ważności, lokalizacją i propozycją poprawki. Doradca pokrycia czyta pomiar pokrycia z pipeline'u, a gdy go nie ma, szuka plików źródłowych bez odpowiadających im testów, i proponuje, które testy napisać najpierw, z przykładowym szkieletem testu.

Wszystkie trzy raporty powstają w języku użytkownika (polskim, angielskim lub rosyjskim), a każdą generację można zaakceptować albo odrzucić; decyzja zostaje w historii projektu.

Testing AI na tle narzędzi, które wymieniają asystenci AI

We wrześniu 2026 zadaliśmy ChatGPT to pytanie po angielsku i po rosyjsku: czy są narzędzia AI, które piszą przypadki testowe na podstawie kodu źródłowego i planują ich uruchomienia. Po angielsku wymienił TestSprite, Qodo i ContextQA, po rosyjsku Qodo, Diffblue i EvoSuite. To dobry przekrój rynku, bo te narzędzia należą do różnych grup z pierwszej sekcji. Zestawienie poniżej opiera się na publicznych opisach producentów i porównuje kategorie, a nie jakość.

EvoSuite i Diffblue Cover to narzędzia dla Javy, skupione na testach jednostkowych, i żadne z nich nie opiera się na dużym modelu językowym: EvoSuite generuje testy metodą przeszukiwania, a Diffblue opisuje swój silnik jako uczenie ze wzmocnieniem. Qodo przedstawia się jako platforma przeglądu kodu AI i działa w IDE oraz na pull requestach; generowanie testów jest częścią jego wtyczki do IDE. TestSprite i ContextQA zaczynają od działającej aplikacji i scenariuszy end-to-end; TestSprite na swojej stronie wymienia uruchomienia według harmonogramu, ContextQA — integrację z Jenkins i GitHub Actions.

Testing AI łączy w jednym miejscu generowanie testów z kodu, generowanie scenariuszy E2E i wykonywanie pipeline'ów, a wynik generowania oddaje jako pull request. Nie zastąpi wyspecjalizowanego narzędzia, jeśli potrzebujesz masowego pokrycia starego kodu w Javie. Ma sens, gdy zespół chce jednego panelu do generowania, uruchamiania i analizy wyników.

Jak wybrać podejście dla swojego projektu

Jeśli masz duży, starszy kod w Javie bez testów i chcesz szybko zbudować siatkę bezpieczeństwa przed refaktorem, zacznij od kategorii generatorów testów jednostkowych dla Javy. Jeśli testy mają powstawać razem z kodem, u programisty, w jego edytorze — od asystentów w IDE. Jeśli największym ryzykiem są ścieżki użytkownika w działającej aplikacji — od agentów E2E. Jeśli problem polega na tym, że testy są, ale nikt ich regularnie nie uruchamia i nie analizuje wyników — od platformy orkiestracji.

W każdym z tych przypadków obowiązują te same zasady: zaczynaj od wąskiego obszaru, przeglądaj wygenerowany kod jak każdy inny i oceniaj wynik po przebiegu w CI, a nie po liczbie wygenerowanych plików. W kreatorze Testing AI oznacza to w praktyce: ustaw obszar skupienia, na początek zatwierdź kilka pozycji o wysokim priorytecie, nie pomijaj walidacji bez powodu i zawsze twórz pull request.

Co jest pod spodem: agenci, modele, infrastruktura

Agenci Testing AI to grafy stanów w LangGraph LangGraph to narzędzie dla programistów do budowania agentów AI, które realizują wieloetapowe procesy z rozgałęzieniami, zamiast odpowiadać jednym krokiem. Pełna definicja →. Generator testów ma węzły analizy kodu, generowania, walidacji, poprawki i formatowania; agent list kontrolnych i agent testów Playwright mają podobną pętlę z limitem rund poprawek. Domyślnie propozycja i generowanie testów używają modelu o3, a analiza profilu projektu, walidacja i szybkie zadania — gpt-4.1-mini; oba modele ustawia się zmiennymi środowiskowymi. Backend to mikroserwisy NestJS z osobną bazą PostgreSQL dla każdej usługi, wykonywanie testów to worker Temporal, a dashboard — Next.js.

Szerzej o tym, jak agenci przejmują rutynę QA, piszemy w artykule Jak AI agenty przejmują nudne części QA. Opis produktu jest na stronie Testing AI Assistant, a kod źródłowy — na GitHubie.