13. juli 2011 - 15:00Der er
10 kommentarer og 1 løsning
Unit testing
Hej, Jeg er ret ny til unit testing, jeg har ikke brugt det ret meget i hvert fald men vil nu til at kigge lidt på det. Man bør jo nok når man laver TDD skrive sine tests før man skriver metoderne (det syntes jeg at have læst i hvert fald), men dette har jeg ikke gjort.
Mit system har ikke frygtelig meget "forretningslogik". Dermed ment at jeg f.eks. bare udfylder nogle textboxe og tilføjer/sletter i en database.
Hvordan skal jeg gribe det an? Folk laver vel mest units tests til forretningslogik og ikke så meget til om man kan indsætte i en database uden fejl idet man nok bør have noget validering (som man kan lave unit tests på) tidligere i forløbet. Ville der være ide i at lave en unit test på om man f.eks. kan lave en "update" af en give række i en database og hvis ja, hvordan gør man det smartest? Jeg vil jo i bund og grund ikke opdaterer rækken men blot teste for det. Skal jeg ud i noget "mock" her eller er det en forkert vej?
Jeg er lidt på bar bund, så tips og tricks omkring unit tests er velkomne :)
Hvis jeg f.eks. har en "HentAllePersoner" metode og så laver en unit test som forventer at 10 personer bliver returneret, så virker det jo fint fordi jeg som sådan ikke gør noget i databasen, men hvis jeg derimod vil teste om den opdaterer eller sletter korrekt har jeg jo et problem idet jeg ikke vil fjerne rækken "rigtigt".. How to?
Spørger lige om det samme igen, men bør man teste noget på database niveau på den her måde overhovedet?
Du boer unit teste al kode som kan indeholde fejl. Det er AL KODE. Saa det er ikke kun business logic kode.
Det anbefales normalt at skrive unit tests inden implementation, fordi ellers kan man nemt teste om koden goer det den goer fremfor om den goer det den skal goere.
Forskellen paa TDD og ikke-TDD er om det at skrive unit test er en del af design fasen eller det foerste man goer i implementations fasen.
"Hvis jeg f.eks. har en "HentAllePersoner" metode og så laver en unit test som forventer at 10 personer bliver returneret, så virker det jo fint fordi jeg som sådan ikke gør noget i databasen, men hvis jeg derimod vil teste om den opdaterer eller sletter korrekt har jeg jo et problem idet jeg ikke vil fjerne rækken "rigtigt".. How to?
Spørger lige om det samme igen, men bør man teste noget på database niveau på den her måde overhovedet?"
Så skal du lave en mock af til din serviceklasse som indeholder HentAllePersoner. Mocken skal du så bruge i din unittest, herigennem finder du frem til om HentAllePersoner giver dig det du forventer. Dvs. mocken kender du.. den indeholder 10 personer og unittesten forventer 10 personer.
Bagefter skal du lave en integrationstest imod db'en, her skal du i alle dine tests indsætte i tabellen og bagefter hente og slutteligt rydde op efter dig. DB'en er nem at lave integrationstests imod fordi du sædvanligvis gerne må indsætte data, men lad os sige du skulle integrationsteste en webservice eller måske en eventlogger, så ville du blot teste at den var integreret korrekt og kunne hhv. komme med et response og logge uden fejl.
Kort fortalt er unittest isoleret til units og integrationstests er hvor man har gang i noget infrastruktur :)
Hej igen, Okay, så er jeg med.. jeg smider simpelthen data i databasen og bare rydder op bagefter.. jeg fandt dog en video på youtube omkring dette.. det kan være i kan fortælle om det er en god/dårlig ide det han har gang i? Jeg ville da klart foretrække ikke at skulle til at rydde noget op :)
Hvis du vil unit teste kode som laver database operationer, saa er du i sagens natur noedt til at lade koden lave database operationer. Ellers tester du noget andet end det som skal koeres. (*)
*) Principielt burde man lave en database server mockup, men det her er den virkelige verden.
Tricket i den video er noget pjat. Det kan kun bruges ved meget simple ting.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
