Unit testing – en hurtig introduktion
2020: Denne er artikel er blev opdateret, du kan læse den nye version [her] (https://martinschultz.dev/posts/2020-03-03-unittests-en-hurtig-guide/).
Hvad er unit testing
Unittesting 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 hutig introduktion til at lave unit tests i C# under Visual Studio.
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øre testene kan føle sig rimeligt 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.
Hvordan gør man
Til .NET er der to måder at lave unittests på, nUnit (open source) der er det ældste værktøj til formålet samt Visual Studio Team Test der er microsofts bud og er indbygget i Visual Studio (desværre ikke i den gratis express udgave, kun i betalingsversionerne). I dette artikel vil jeg bruge Team Test men forskellen på de to er ikke så stor rent kodemæssigt, men i hvordan man køre testene. I Team Test kan man køre dem direkte i Visual Studio, mens nUnit kræver at de køres fra et eksternt program.
For at lave en unit test skal man blot højreklikke på den funktion man vil teste og vælge ”Create Unit Tests…”
Første gang man gør det vil man blive guided igennem skabelsen af et test projekt. Det viste eksempel er en simpel rekursiv funktion der vender en tekst streng om.
Når man har fulgt guiden til test projektet vil man skulle skrive selve test koden, der bare er nrmalt C# kode med enkelte ”nye” muligheder. Min test til reverse ser sådanne ud:
Når man så kører testen vil resultatet blive vist i testvinduet.
Og i dette tilfælde kan man se det gik godt. Muligheden for at køre testen får man ved at vælge Test i Visual Studios top menu, derefter Windows og Test View. Gik det ikke godt stod det i Result kolonnen og fejlen stod i Error Message kolonnen.
Den del der bestemmer om hvorvidt testen er en success er den linie med Assert. 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, dvs 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
-
Guide fra Microsoft: http://msdn.microsoft.com/en-us/library/ms379625(v=vs.80).aspx