Jonas MidstrupIT & BusinessSearchMain menuSkip to primary contentSkip to secondary contentHomePost navigation← Older postsTest Driven Development i softwareprojekterPosted on October 27, 2013  by  jonasmReplyFor et par uger siden var jeg en tur i Oslo i forbindelse med min deltagelse i graduate programmet i Visma Consulting. En fantastisk tur, hvor vi bl.a. blev introduceret til Visma koncernen og mødte de norske graduates (“Nytt Krutt”, som det kaldes deroppe). En del af turen gik desuden med et kursus i Test Driven Development (TDD), hvor vi først blev bedt om at skrive et simpelt brætspil uden tanke på test. Derefter blev vi bedt om at skrive spillet om, hvor vi denne gang skulle skrive unit tests til spillet før vi skrev selve koden. Til sidst blev vi introduceret til mocking og denne måde at skrive unit test på. Ved alle disse forskellige måder at skrive spillet på, blev vi bedt om at programmere det hele sammen med minimum én anden udvikler (par-programmering).Test Driven Development som metodeSom en del af min bacheloruddannelse har jeg kortvarigt stiftet bekendtskab med eXtreme Programming (XP). Flere af de idéer der var/er en del af denne metode, går umiddelbart også igen i TDD. Begge er agile softwareudviklingsmetoder, men som navnet antyder, så er der i TDD stort set kun fokus på test. Den store parallel mellem TDD og XP er et koncept fra XP kaldet “test first” der bl.a. siger, at når man skal skrive ny kode, skal man starte med at skrive unit testen. Denne idé gennemsyrer hele udviklingsprocessen i TDD:Test Driven Development CycleUmiddelbart virker det for mig ligegyldigt, at skrive kode til en unit test, før man har skrevet noget kode der kan testes. Det har dermed i praksis en stærk association til det kendte spørgsmål om “hønen og ægget”. Den grundlæggende idé med at skrive testen først, er at udvikleren får en forståelse for de krav der er til det der skal udvikles, gennem fordybning i use cases og user stories, før der bliver skrevet kode. Denne idé er ganske god, men for mig at se burde man starte et skridt før og i stedet gøre det til en del af use casen eller user story, at tilknytte en beskrivelse af hvordan den enkelte feature skal testes eller rettere en beskrivelse af den enkelte tests struktur. På den måde opnår man stadig, at udvikleren forstår det der skal udvikles, dog uden at bruge tid på at skrive en test der endnu ikke har en reference til genstanden for selve testen – den kode der skal skrives. Når koden så efterfølgende er skrevet, kan testen skrives bl.a. ud fra use casen.Test i softwareudviklingsprojekterLad mig først være fuldstændigt ærlig – gennem mine tidligere ansættelser som software udvikler i diverse sammenhænge har jeg desværre aldrig mødt en .NET baseret applikation, hvor der var inkorporeret test. Det skal lige siges at jeg er blevet meget positivt overrasket af det fokus der er på test i Visma og det mener jeg også skinder i gennem i koden.Der