Microsoft har open-sourcet code-testing-generator, en polyglot testagent, der ikke bare genererer unit tests, men også kører dem og kontrollerer, at de fungerer. Ifølge MarkTechPost ligger løsningen i dotnet-test plugin’et i dotnet/skills under MIT-licens. På en intern benchmark med 152 opgaver rammer agenten 92,1% gennemførelse mod 78,9% for stock GitHub Copilot, angiveligt på samme model og prompts. Tallene er Microsofts interne resultater, viderebragt af MarkTechPost, og kilden specificerer ikke, hvilken modeltype eller præcise prompts der er brugt.
Samme model, samme udgangspunkt — forskellen ligger i orkestreringen. Agenten kører arbejdsgangen struktureret og verificerer, at nye tests faktisk bliver opdaget og passerer i projektets virkelige build- og testrutiner. Det er her, værdi opstår i praksis, især i komplekse repos.
Hvad værktøjet gør i praksis
code-testing-generator fungerer som en mellemmand mellem din kode og projektets testkonventioner. Den læser repoet, vælger testframework, filplacering og passende assertions ud fra eksisterende praksis. Før den skriver, orienterer den sig i repoets faktiske struktur og mønstre — netop det, der ofte mangler i one-shot generering.
Agenten stopper ikke ved “kode genereret”. Den melder først færdig, når tests er kørt og har passeret en verifikations-gate. Det er forskellen på mange linjer testkode og ændringer, som faktisk opfanges i CI og giver troværdige signaler.
RPI-pipelinen kortlagt
Arbejdet styres som en Research-Plan-Implement-pipeline. Ifølge MarkTechPost leder agenten først i repoet efter kode, der mangler tests, opdager sprog og testframework, læser eksisterende tests for at lære konventionerne, og finder de reelle build- og test-kommandoer. Det sidste reducerer klassiske fejl, hvor noget bygger lokalt, men ikke bliver samlet op i CI.
Når planen er lagt, vælger agenten mellem tre strategier: Direkte (skrive og validere med det samme), Single pass (én fuld cyklus) eller Iterativ (flere runder mod et dækningsmål). Pointen er, at orkestreringen vægtes lige så højt som selve genereringen.
Verifikations-gate med fem dokumenterede checks
Inden agenten markerer “done”, kører den fem checks, som MarkTechPost beskriver. 1) Ræsonnerer over små kodeændringer, der burde få testen til at fejle — en let udgave af mutation testing. 2) Finder svage eller manglende assertions. 3) Mapper ønskede scenarier til konkrete tests, så dækning bliver sporbar. 4) Bygger hele workspace og kører hele suites, ikke kun en enkelt fil. 5) Bekræfter, at repoets egen test-kommando opdager de nye tests. Det er lavpraktisk — og netop derfor vigtigt. Det forhindrer commits, der aldrig eksekveres i pipeline.
MarkTechPosts gennemgang af disse fem trin er central for at forstå, hvorfor agentens resultater adskiller sig fra en ren “skriv tests”-prompt: verifikation, ikke bare generering.
Distribution, hosting og compliance
Værktøjet distribueres som en agent-definition med skills og kører i jeres eksisterende miljø, ikke som en hosted service. Koden forlader ikke maskinen. Ifølge kilden ændrer agenten ikke produktionskode og undgår tests med eksterne kald, port-binding og tidsafhængigheder for at reducere sideeffekter og flaky adfærd. I praksis giver det en klar governance- og compliance-fordel for organisationer med skrap kontrol af kildekode og artefakter.
Begrænsningen følger med: Kode med rigtige integrations- eller tidsafhængigheder hører hjemme i andre lag (kontrakt- eller integrationstests). Det bør være tydeligt i jeres evalueringskriterier, så værktøjet vurderes på det område, det er designet til.
Benchmarken og hvad tallene egentlig siger
På Microsofts interne benchmark med 152 opgaver fra rigtige repos gennemførte agenten 140 (92,1%) mod 120 for stock Copilot (78,9%), på samme model og prompts. Ifølge MarkTechPost er gevinsten koncentreret i to typer opgaver: På 89 vage prompts klarede agenten 79 (88,8%) mod 59 (66,3%), hvilket reducerede fejl fra 30 til 10. På 63 detaljerede prompts scorede begge 61 (96,8%). På 15 diff-specifikke opgaver passerede agenten alle 15, mens stock Copilot ikke passerede nogen.
Flere datapunkter fra kilden: Agenten genererede 2,3% færre tests (6.963 mod 7.129) ved næsten samme linedækning (72,4% mod 72,2%). Gennemsnitlig opgavetid var 359 sekunder mod 380, og tokenforbruget per gennemført opgave var 3,2% højere. På 45 .NET-opgaver nåede Claude Opus 4.8 43\/45 med agenten mod 35\/45 stock; GPT-5.5 nåede 41\/45 mod 36\/45. På den sværere eksterne SWE Atlas-benchmark lød tallene 16\/44 mod 12\/44. Eksterne reproduktioner beskrives ikke i kilden, og modeltype samt præcise prompts er ikke oplyst.
Hvorfor det betyder noget i CI\/CD
Tre ting der flytter nålen i praksis: 1) Agenten identificerer projektets faktiske build- og test-kommandoer, så nye tests bliver opdaget af CI. 2) Verifikations-gaten reducerer risikoen for svage tests, der passerer tilfældigt. 3) RPI-pipelinen indkoder implicit repo-viden og sænker friktionen ved PR’er, især når teams er små eller monorepoet er uensartet.
Det er præcist dér, mange teams taber tid: uens konventioner, forældreløse testprojekter og manuelle “hvor skal den fil egentlig ligge?”-diskussioner. Agentens systematik gør en forskel her.
Praktisk integration uden at afgive kode
En fornuftig pilot starter med 1–3 moduler med høj testgæld og kontrollerbar risiko. Kør agenten som en separat branch- eller PR-producerende proces, med review af en fast gruppe og en gate, der kræver, at nye tests både kører lokalt og opdages af CI-kommandoen. Placér research og plan som “tørkørsel”, der kun udleder build- og test-kommandoer, fulgt af implement- og validate-trin i en sandboxet runner med lukket netværk. Gem artefakter, logs og diffs i artefaktlager til audit.
En enkel måleskabelon for piloten på 4–8 uger: følg linjedækning, flakiness-rate, PR-fail-rate, tid per CI-opgave og tid til review. Evaluer, om agentens forslag følger jeres konventioner uden store manuelle rettelser, og om feedback-loopet faktisk bliver kortere.
Mini-eksempler fra hverdagen
Forestil dig en PR med en lille ændring i en util-klasse. Agenten mapper diff’en til en ny testsag, placerer testen i det rigtige projekt og sikrer, at repoets test-kommando samler den op. Reviewer ser en konkret assertion og et grønt signal i CI — ikke bare genereret kode, men integreret test.
Eller et modul uden eksisterende tests: Agenten læser nabomodulers konventioner, vælger samme framework og struktur og laver en første bølge af målrettede tests, som går gennem verifikations-gaten. Det gør backfill håndterbar i batches, ikke som ét stort spring.
Når værktøjet flytter mest værdi
Større monorepos på tværs af sprog og frameworks, platformteams med testgæld og kodebaser med mange PR’er pr. uge mærker effekten tydeligst. Agenten kan backfille tests og standardisere konventioner. Solo-maintainere og mindre startups kan også hente tid, fordi research-delen ellers stjæler fokus.
Små kodebaser med høj dækning og klare konventioner vil se mindre løft. Hvis flaskehalsen ligger i integrationstests, performance eller datamigrering, er unit-testlaget ikke det rigtige sted at optimere først.
Fælder og driftsmæssige spørgsmål
Før bred udrulning, få styr på: valg af modellag og versionering af prompts; om navne-, placerings- og assertion-konventioner skal forgrenes pr. team eller centraliseres; regler for karantæne eller sletning af flaky tests; sandboxing, så eksterne kald ikke sniger sig ind via fixtures; og sporbarhed, så commit-beskeder refererer til agentkørsler og verifikationsresultater.
Konkrete drifts- og kapacitetskrav (CPU, RAM, IO, disk, timeouts) er ikke beskrevet i kilden. Planlæg derfor at måle ressourceforbrug i piloten og justér runners og parallelisering derefter.
Supply-chain og governance i enterprise
Overvej en minimal governance-model: signér og versionér agent-definition og skills internt, ejerskab hos et platformteam, og en fast kadence for regressionstests af agenten i CI. Hold revisionsspor for ændringer i prompts, konventioner og policies. Centraliseret styring behøver ikke at være tung — men uden den risikerer man divergerende praksis på tværs af teams.
Kontekst og sammenligning
Hvorfor ikke bare bede Copilot eller en vilkårlig LLM om at “skrive tests”? Ifølge MarkTechPost er forskellen størst, når prompten er vag, eller når opgaven er at målrette et diff. Orkestreringen i RPI og verifikations-gaten leverer robusthed, ikke kun output. Og lokal kørsel er for nogle et afgørende krav.
Andre værktøjer og agent-arkitekturer, ofte hosted, tilbyder også testgenerering. Fordelen her er kontrol og audit; omvendt ligger opsætning, ressourcer og vedligehold hos jer. Det er et klassisk drift kontra bekvemmelighed-valg, som bør afklares tidligt.
Usikkerheder og åbne spørgsmål
MarkTechPost nævner “samme model og prompts”, men uden at specificere modeltypen. Det gør generaliserbarhed sværere at vurdere. Fejlhåndtering og edge cases beskrives heller ikke i dybden, eksempelvis detektion af sideeffekter eller håndtering af ikke-deterministiske kodebaser.
Kilden angiver gennemsnitlig opgavetid og tokenforbrug, men ikke CPU, IO og RAM-krav, som er relevante for kapacitetsplanlægning. Der er heller ikke oplysninger om omfang af sikkerhedsrevision, signering af skills eller enterprise-deploy-patterns. Tag derfor piloten som måleperiode og dokumentér krav i jeres egen pipeline.
Bundlinjen i morgen
Har I testgæld og komplekse builds, er det værd at prøve code-testing-generator lokalt i en stram pilot. Start småt, mål hårdt, og fold først ud, når signalet er stabilt. Effekten mærkes, når værktøjet faktisk kører i jeres pipeline — ikke på papiret.
