Unit-testing – den pragmatiske vs. TDD
Som nævnt har vi ændret vores projekt radikalt – i den forbindelse blev vi enige om, at tage unit-test noget mere seriøst. Vores oplevelse var at vi brugte uforholdsmæssigt lang tid på at rette tåbeligheder (stavefejl i SQL-sætninger og den slags), som burde have været fanget inden koden tog sit indtog på vores SVN-repository. Det kostede os en del timer sent i implementeringen (hvor scenariet var så tilpas komplekst at det bliver svært at finde en stavefejl).
Vi havde egentlig tænkt os at lave unit-tests under hele forløbet, men vi havde ikke rigtig fundet os til rette med det. Vores tilgang/metode minder mest om XP (Extreme Programming) og derfor havde vi ofte et par forskellige løsningsmodeller som vi gerne ville have afprøvet inden vi valgte en for at se om de passede ind i det store design. Det virkede umiddelbart som et stort tidsspilde at skrive tests til alle versionerne, inden vi havde besluttet os for modellen.
TDD (Test Driven Developement) var kort oppe til diskussion, men blev forholdsvis hurtigt forkastet – dels havde ingen af os erfaring med det, og dels passer det ikke ret godt med vores temperament. Men efter at have læst op på det (vi prøver at forkaste ting på et rimeligt grundlag…) var der stadig nogle ting, der rigtig fornuftige ved fremgangsmåden, så vi valgte at tage et par af lektierne med os.
Vi kører nu unit-tests på alt det vi mener er relevant at unit-teste på. Vi prøver så vidt muligt at opnå en coverage på min. 80% på alle klasser med nogle enkelte undtagelser. File-adapters har fx vist sig svære at teste i praksis – eftersom vi sætter NCover til at teste for os, har vi ikke mulighed for at kende filstier osv. til at lave tests af det. Derudover er vi ikke rigtig kommet i gang med unit-tests af vores UI. Dels er der ikke nogen af de test-suiter vi har testet, som heelt er oppe på omgangshøjde med .Net 3.5 – og dels er skærmbilleder per definition svære at lave unit-tests af, da de har nogle afhængigheder af det underliggende system, som vi ikke har kontrol over.
Men bare den mængde unittests vi laver nu, har givet os en væsentlig bedre kodekvalitet. Og vi sparer os selv for nogle alvorlige tømmermænd med hensyn til små tåbelige fejl, vi ikke ville have fundet før der var en bruger, der var fræk nok til at teste systemet i hjørnerne. Og sjovt nok giver det os mulighed for at give hinanden en opskrift på eksempler af brug af vores klasser, som rent faktisk virker. Det vil sige at i stedet for at skulle forklare i dokumentationen, hvordan og i hvilke tilfælde metode A er bedre end B, kan vi nu blot henvise til Unit-testen, som på en let forståelig måde kan vise praktisk brug.
Vores projektgruppe er meget lille (vi er for tiden 2, men vi håber at vi når op på 3 senere på året) – og det vil sige at kommunikation ikke burde være en af de helt store problemer, men alligevel har vi opdaget, at det er det faktisk. Ikke ment på den måde at vi er i tvivl om, hvad den anden laver – eller for den sags skyld, hvordan vores kode virker. Næh, problemet er snarere at vores interne sprog er ufuldstændigt. Vi kalder ikke tingene for det samme – og når vi bliver bare det mindste tekniske, har vi nemt ved at tabe hinanden – eller værre endnu tale forbi hinanden.
Som konklusion kan man sige, at de timer vi har brugt på at sætte os ind i unit-testingens vidunderlige univers har betalt sig mange gange tilbage. Det er svært at måle på bundlinjen, men bare stabiliteten af applikationen er blevet rystende meget bedre.