Unit tests til embedded: Få AI til at skrive tests

Når de fleste embedded-udviklere prøver generativ AI for første gang, er det næsten altid på kode. Man beder den skrive en driver til en sensor, et unit-setup til en mikrocontroller eller en wrapper til et HAL-interface. Og ofte virker det imponerende godt. 

Men det er ikke dér, AI har størst potentiale i embedded-udvikling. 
Det er i test. 

For det er netop i arbejdet med unit tests, at moderne sprogmodeller viser en af deres mest undervurderede styrker: evnen til at kombinere krav, variationer og edge cases på en måde, der minder mere om en erfaren testingeniør end om en kodegenerator. 

Hvorfor tests er sværere end kode 

At skrive en driver handler i høj grad om mønstre. Initialiser periferi, sæt registre, læs og skriv data. Den slags findes der tusindvis af eksempler på i den kode, AI-modeller er trænet på. 

Men at skrive gode tests er noget andet. Her skal man forstå, hvad systemet skal gøre, forestille sig hvad der kan gå galt – og bevidst prøve at få det til at fejle. Det kræver, at man tænker i adfærd, ikke bare i syntaks. 

Det er præcis derfor, AI ofte skuffer, når man bare beder den “skrive tests”. Hvis den ikke får den rigtige kontekst, begynder den at gætte. Den opfinder registre, timingkrav eller funktioner, der ikke findes, fordi dens grundmodel er trænet til at fortsætte tekst – ikke til at kende sandheden om dit system. 

Nøglen er kontekst 

Vil man bruge AI seriøst til embedded tests, skal man give den den samme information, som en testingeniør ville få. Det betyder ikke bare kildekoden, men også: 

• headerfiler og interfaces 
• registerdefinitioner 
• protokolbeskrivelser 
• timingkrav 
• uddrag fra datasheets 

Når du gør det – og samtidig beder modellen om kun at bruge den information – stopper den med at opfinde detaljer og begynder at arbejde inden for dine faktiske rammer. Pludselig skriver den ikke “fantasi-tests”, men tests, der passer til dit konkrete hardware og din firmwarearkitektur. 

Få AI til at tænke som en tester 

En anden vigtig forskel ligger i, hvordan man stiller opgaven. Sprogmodeller er markant bedre, når de får lov til at arbejde sig gennem et problem trin for trin. 

I stedet for blot at bede om unit tests kan man bede modellen om først at identificere, hvad koden skal kunne, derefter hvilke fejl der kan opstå – og først til sidst skrive testene. Det tvinger den til at gøre det, en erfaren testingeniør gør i hovedet: bryde problemet op i krav, risici og verifikation. 

Resultatet er tests, der ikke bare dækker “happy path”, men også timeout, grænseværdier, manglende svar fra hardware, ugyldige input og andre situationer, som ofte først opdages sent – eller i felten. 

Stærkest dér, hvor mennesker er svage 

Noget af det mest interessante ved AI-genererede tests er, at de ofte rammer de steder, vi selv overser. Mennesker tester ud fra deres mentale model af systemet. Sprogmodeller tester ud fra mønstre i variationer. 

Det betyder, at de kan finde mærkelige kombinationer af input, uventede rækkefølger af kald eller grænsetilfælde, som sjældent står øverst i en udviklers bevidsthed – men som netop er der, fejl gemmer sig. 

Kombineret med mocks og et simpelt HAL-lag kan AI også hurtigt generere simulerede svar fra sensorer og periferi: normale målinger, forsinkede svar, støj, fejltilstande. Det giver langt bedre testdækning uden at kræve fysisk hardware på bordet. 

Men AI skal ikke have det sidste ord 

En vigtig læring fra generativ AI er, at modellen ikke er trænet til at være korrekt – den er trænet til at være overbevisende. Derfor skal alle tests, den genererer, stadig gennemlæses, kompileres og køres. 

Forskellen er bare, at du ikke starter fra et tomt dokument. Du starter med et udkast, der allerede dækker langt mere, end de fleste teams når i praksis. 

Mange embedded-teams begynder derfor at arbejde på en ny måde: 
De skriver koden, giver den til AI sammen med interfaces og krav – og får derefter et helt batteri af tests, edge cases og mocks retur, som de kan raffinere og køre. 

Resultatet er færre fejl, hurtigere feedback og mere robust firmware. 

AI skriver måske ikke perfekt kode. 
Men den kan hjælpe dig med at bevise, at din kode virker – og det er i sidste ende det, der betyder noget.