Unit testing – en hurtig introduktion

Jeg skrev tilbage i 2011 en kort artikel omkring unit testing i visual studio der stadig er populær men da visual studio har ændret sig en del siden da tænkte jeg at det var på tide med en opdatering. Unit testing er en er en metode til at teste et program ved at dele et program op i små dele (units) lave automatiserede tests af disse imens programmet bliver udviklet. Denne guide er en hurtig introduktion til at lave unit tests i C# under Visual Studio. Der er et link til at downloade test projektet i slutningen af artiklen.

Hvorfor unittesting

Formålet er at man tester programmet kontinuerligt under udviklingen således at man hurtigt bliver opmærksom på problemer og nemt kan løse dem uden de store omkostninger. Derudover gør unittests det nemmere at ændre i koden senere da man ved at genkører testene kan føle sig mere sikker på at man ikke at ødelagt den eksisterende funktionalitet.

Hvad er en unit

Hvad en unit er afhænger naturligvis af projektet og dets indhold men følgende er generelt udtryk for hvad man bør anse for en unit og teste:

Klasser Funktioner Stored procedures Web services Nogle vil mene at ”skærmbilleder” og andre ting også falder ind under hvad der skal testes som en unit men det er langt henad vejen op til en selv. Personligt synes jeg at skærmbilleder er en underlig størrelse at gøre til genstand for tests.

Hvordan gør man

Til .NET med Visual Studio er der nu kun en generel måde at lave unittests på. Jeg har til formålet lavet et meget simpelt .NET core program der bare vender en tekst streng om (hej bliver til jeh). For at oprette unit tests kan man simpelthen højre klikke på den funktion man vil teste og vælger ”Create Units Tests” (den funktion man tester skal være i en klasse der er defineret som ”public”).

create unit tests

Så vil man blive bedt om at oprette et test projekt som ens tests kan tilhører, hvis man ikke har et i forvejen. Nu har du grundstenen til en test funktion, men pt er den eneste kode i funktionen er Assert.Fail(), hvilket bare betyder at testen tæller som fejlet. Unit test kode Så skal man skrive selve koden til test af funktionen, du kan se mit meget simple eksempel i det følgende:

simpel test

Her bruger jeg Assert.AreEqual hvilket sammenligner to resultater, nemlig det aktuelle og det forventede resultat og returnere succes hvis de er ens. Andre muligheder er:

unit test typer

Generelt har unit test funktioner return typen void og bruger Assert funktionen til at angive resultatet. For at kører testene skal man gå tilbage til sin funktion, højreklikke og vælge ”Run Test(s)”. Læg mærke til at visual studio nu over funktionen viser at der er en unit test til den og dens status.

test status

Nu kommer test vinduet frem hvor man kan se status for sine tests og afvikle dem. Den skriver også hvor længe det har taget at kører testen.

unit test run

Og i dette tilfælde kan man se det gik godt ved de grønne check marks. Gik det ikke godt var der røde ikoner og fejlen vil stå i Error Message kolonnen. Den del der bestemmer om hvorvidt testen er en succes som tidligere nævnt Assert funktionen. Der er flere forskellige muligheder for at teste resultatet med Assert, i dette tilfælde har jeg brugt AreEqual hvor den sammenligner to strings og siger ok hvis de er ens. Man kunne også have valgt at teste på de ikke er ens, at de ikke er null og et utal af andre muligheder.

Hvor mange tests bør man lave?

Der snakkes meget om code coverage og der findes værktøjer til at måle hvor stor del af koden der testes men umiddelbart falder det tilbage på sund fornuft. Man bør teste nok til at man har ro i maven om at det vigtige i ens program testes automatisk. Generelt vil jeg sig at man bør koncentrere sig om to dele, det vigtige og det svære/uigennemskuelige.

Best Practice

Alle unittests bør være selvstændige og komplette, de bør ikke referere eksterne ”units” som for eksempel databaser. Her bør man i stedet bruge stubs og interfaces.

Unitstests må ikke være afhængige af andre unittests, det vil sige de må ikke skulle køres i bestemte række følger. Unittests skal være automatiske, de må ikke kræve nogen form for brugerinput eller holden i hånden.

Referencer

Test Driven Development: By Example af Kent Beck

Test projektet til download.