A teszt a promptban: működik
Erre van tiszta mérés. Egy 2024-es konferenciacikk három helyzetet hasonlított össze: csak feladatleírás; feladatleírás plusz megadott tesztek; és ugyanez javítási körrel a bukott tesztek visszajelzéséből. Két modell, két bevett feladatkészlet, plusz 1 100 versenyfeladat.
| Modell és feladatkészlet | Tesztek a promptban | + javítási kör |
|---|---|---|
| Erős zárt modell, egyik készlet | +12,0% | +2,8% |
| Erős zárt modell, másik készlet | +8,5% | +3,0% |
| Erős zárt modell, 1 100 versenyfeladat | +7,3% | — |
| Nyílt súlyú modell, egyik készlet | +29,6% | +9,0% |
| Nyílt súlyú modell, másik készlet | +13,4% | +8,5% |
A haszon egyértelmű, és minél gyengébb a modell, annál nagyobb.
De van két korlát, amit a szerzők maguk írnak ki.
Az egyik: több teszt nem mindig jobb. Ahogy nő a megadott tesztek száma, „bizonyos esetekben elromlik olyan kód, ami korábban helyes volt". Az ok a hosszú kontextusban elvesző információ. Van egy optimum, és azon túl romlik.
A másik fontosabb: a megadott teszteken átmenő megoldás gyakran megbukott a rejtett teszteken. Vagyis a modell a megadott tesztre optimalizál, nem a helyességre. Ez nem hiba, hanem a feladat természete — de tudni kell róla.
A teszt, amit az agent ír magának: nem működik
Ez a rész kijózanító, és pont az ellenkezőjét mutatja annak, amit várnál.
Egy 2026-os mérés hat modellt vizsgált ugyanazon az 500 feladatos, valódi repókból álló készleten. Két szélsőérték:
- Az egyik modell a feladatok 83%-ában írt magának tesztet. Megoldási aránya: 74,4%.
- Egy másik a feladatok 0,6%-ában. Megoldási aránya: 71,8%.
2,6 százalékpont különbség — miközben az egyik szinte mindig tesztel, a másik szinte soha. És amikor prompttal megtiltották a tesztírást a sokat tesztelő modelleknél, az eredmény alig változott: ötszáz feladatból nettó tíz körüli elmozdulás.
A magyarázat a cikk igazi tanulsága: az agent által írt „tesztek" nagyrészt nem ellenőrzések, hanem megfigyelőeszközök. A mérés szerint az értéket kiírató sorok következetesen többen vannak, mint az állítások. Ez debug-nyomtatás, tesztnek öltözve.
A különbség tehát nem az, hogy van-e teszt. Hanem hogy ki mondja meg, mi a helyes eredmény. Ha a modell írja a tesztet a saját kódjához, akkor a saját értelmezését ellenőrzi.
Amikor a teszt félrevisz: a hibát betonozó teszt
Itt van a legfontosabb mechanizmus, és ez adja a cikk címét.
Egy 2026-os vizsgálat azt nézte meg, mi történik, ha a már meglévő, hibás kód ott van a promptban, és tesztet kérsz hozzá. Az eredmény: a modell a hibás viselkedésre ír állítást, ahelyett hogy leleplezné. A hibás kód „a hibás viselkedést igazoló tesztek felé tereli a modellt, nem a felfedésük felé".
És kettős a hatás: nemcsak a félrevezetett tesztek száma nő, hanem csökken a hatékony, hibát találó tesztek generálása is.
A szerzők mérték a megoldást is: ne a kódot tedd a promptba, hanem a specifikációt — azt, hogy mit kellene csinálnia. Ez „érdemben csökkenti a félrevezetett teszteket, miközben jelentősen növeli a hatékonyakat".
Ezért nem stílusdivat a „először a teszt". Ez az egyetlen ismert módja annak, hogy a generált teszt ne a meglévő hibát betonozza be: ha a kód még nincs meg, a modellnek nincs mit lemásolnia.
Egy árnyalat a tisztesség kedvéért: ugyanez a vizsgálat azt is megállapította, hogy a hibás kódhoz generált, azon átmenő tesztek többsége a javított változaton is átmegy — vagyis sok teszt egyszerűen semmilyen viselkedést nem köt le. A korábbi irodalom ezt túlbecsülte.
Mennyire szoros a háló?
Érdemes tudni, hol a teszt mint biztonsági háló határa — és erre van kemény adat egy akadémiai környezetből.
Egy 2026-os konferenciacikk 77 javítást nézett át kézzel, három agent kimenetéből, a legjobban kurált iparági feladatkészleten. Az eredmények:
- A javítások 7,8%-a „helyesnek" számított, miközben megbukott a fejlesztők tesztkészletén.
- A „valószínűleg jó" javítások 29,6%-a a valódi javítástól eltérő viselkedést produkált.
- Összességében a bejelentett megoldási arányok 6,4 abszolút százalékponttal felfújtak.
Az ok egyszerű: a mérce csak azokat a tesztfájlokat használja, amiket az eredeti pull request módosított — a többi funkcionalitás teszteletlen marad.
Ha ez így van egy gondosan összeállított akadémiai készleten, a saját repódban nem lesz jobb. A teszt csak azt méri, amit mér.
Mikor jelent valamit a lefedettség?
Erre is van friss mérés: tizenegy modell, tizenhárom beállítás, 8 268 generált tesztkészlet, 101 123 egyedi teszteset.
A megállapítás egy mondatban: a lefedettség és a mutációs pontszám haszna erősen helyzetfüggő.
- Ha a kódról feltételezhető, hogy jó — regressziós helyzet, a teszt a meglévő viselkedést őrzi —, akkor ezek a mutatók értelmes jelzést adnak, különösen modellek összehasonlításánál.
- Ha a kód hibás lehet, és épp a hibát akarod megtalálni, akkor már nem megbízható jelzések.
Ez pontosan illeszkedik a fentiekhez. A generált teszt jó regressziós hálónak. Hibafelderítésre nem az.
A jó hír: nem flaky
Egy gyakori félelem, amire a mérés megnyugtató választ ad. Egy ipari és nyílt forrású adatbázisrendszereken végzett vizsgálatban 5 000-nél több tesztfájlhoz generáltak új teszteket, és a bizonytalanul viselkedő („flaky") tesztek aránya 0,00 és 0,29% között mozgott.
A fő ok, ahol előfordult: a teszt olyan sorrendre támaszkodott, ami nincs garantálva — 115 esetből 72-ben, vagyis 63%-ban.
A probléma tehát nem az, hogy a generált tesztek megbízhatatlanul buknak. Hanem az, hogy megbízhatóan nem fognak semmit.
A tölcsér: 100 generált tesztből 18
Van erre ipari referencia, publikált arányokkal. Egy nagy közösségimédia-vállalat automatizált tesztjavító rendszerénél:
Generált teszteset: 100
Lefordul: 100 × 0,75 = 75
Megbízhatóan lefut: 100 × 0,57 = 57
Növeli a lefedettséget: 100 × 0,25 = 25 <- csak ennyi hasznos
Ebből mérnök elfogadja: 25 × 0,73 = ~18
(Saját számítás a közölt arányokból.)
Tizennyolc teszt százból. És ezt egy olyan rendszer produkálta, ami minden generált tesztet lefuttatott, többször, és csak a lefedettségnövelőt engedte tovább.
Ez a legfontosabb üzenet a „generálj teszteket" tanáccsal szemben: a generálás olcsó, a szűrő a munka.
Miért ér annyit a bukó teszt
Van egy 2024-es vizsgálat arról, mennyit ér, ha a modell a saját kódját javítja a hibák alapján. A válasz: számítási költséggel korrigálva a nyereség „szerény, adathalmazonként erősen ingadozik, és néha egyáltalán nincs".
A szűk keresztmetszet viszont nem a javítási képesség, hanem a diagnózis. Amikor egy erősebb modell adta a visszajelzést, az eredmény jelentősen javult. És a szerzők hozzáteszik: még a legjobb modellek is messze elmaradnak attól, amit emberi hibakereséssel el lehet érni.
Ebből következik a legfontosabb gyakorlati szabály: a bukott teszt neve és üzenete külső, nem a modellből jövő visszajelzés. Pontosan az, ami a szűk keresztmetszetet feloldja. Ezért ér többet egy jó bukó teszt, mint tíz kör „próbáld újra".
A recept: négy szintű kapu
1. PROMPT SZINTEN
Ne "írj tesztet ehhez a függvényhez", hanem:
"írj validateEmail függvényt. Példák: [email protected]
igaz, invalid hamis, [email protected] hamis. Implementálás
után futtasd le a teszteket."
-> a példa a specifikáció. A kód NE legyen a promptban.
2. MUNKAMENET SZINTEN
Rögzített cél, amit minden kör után ellenőriz valami.
"Mutasd a teszt kimenetét" - ne az állítást, hogy kész.
3. DETERMINISZTIKUS KAPU
Script, ami blokkolja a kör végét, amíg nem zöld.
Ez az egyetlen, ami nem javaslat, hanem kényszer.
4. MÁSODIK VÉLEMÉNY
Külön ellenőrző, FRISS kontextussal. Aki írta, elfogult
a saját kódjával szemben.
ÉS A KÉT-MODELL MINTA, amit a gyártó maga ajánl TDD-re:
az egyik írja a tesztet, a másik a kódot, ami átmegy rajta.
Egy nyílt kérdés, amit érdemes kimondani
Kerestük, és nem találtunk olyan mérést, ami azt vizsgálná, hogy egy repó meglévő tesztlefedettsége javítja-e az agent eredményét ugyanazon a repón.
Ami van: a promptba tett teszt javít; az agent által írt teszt nem; a mérce tesztkészlete túl szűk. A lefedettség mint repó-tulajdonság és az agent sikeraránya közötti kapcsolat egyelőre mérés nélküli feltételezés. Logikus, hihető — de nem bizonyított.
Tipikus félreértések
- „Generálok teszteket, és megvan a háló." Százból tizennyolc marad használható egy szigorúan szűrt ipari folyamatban is.
- „Ha az agent ír magának tesztet, az jó jel." A mérés szerint alig változtat az eredményen, és amit ír, az nagyrészt kiíratás, nem állítás.
- „Zöld a teszt, tehát jó a kód." Akadémiai mérésben a javítások 7,8%-a számított helyesnek úgy, hogy a fejlesztők tesztkészletén megbukott.
- „Odaadom a hibás kódot, és írasson rá tesztet." Ezzel épp a hibás viselkedést fogja rögzíteni. Specifikációt adj, ne kódot.
- „A generált tesztek megbízhatatlanul buknak." Flakiness-ük 0,3% alatt volt. A gond az ellenkezője: megbízhatóan nem fognak semmit.
Amit érdemes elvinni
A teszt akkor ér valamit, ha te mondod meg, mi a helyes — a promptba tett példa 7–30%-ot javít, az agent saját tesztje gyakorlatilag semmit. És ha a kód már megvan, a generált teszt hajlamos a meglévő hibát rögzíteni ahelyett, hogy megtalálná. Ezért a sorrend: előbb a bukó teszt, aztán a javítás. A generálás olcsó — a szűrés a munka.
Az első agent-feladat kiszabásáról az első feladat egy agenttel poszt szól; a kész kód átnézéséről pedig a generált kód átvizsgálása poszt.