Hovedopgave. Test Driven Development. Troels Jegbjærg Mørch. Diplom i Informationsteknologi linien i Softwarekonstruktion

Transkript

1 Hovedopgave Diplom i Informationsteknologi linien i Softwarekonstruktion Test Driven Development Af Troels Jegbjærg Mørch 25/ Troels Jegbjærg Mørch, studerende Henrik Bærbak Christensen, vejleder

2 Indholdsfortegnelse 1. Indledning Motivation Problemformulering Relateret arbejde Müller et al [5] George et al [6] Kaufmann et al [7] Williams et al [8] Opsummering Test Driven Development Proces og metode Testliste Red/Green/Refactor TDD eksempel Patterns og tips The 3A Pattern Isolated test Learning Test Mock Object Crash Test Dummy TDD afsluttende bemærkninger TDD og The Scientific Method Traditionelt web-projektforløb i Jyske Bank Brugen af automatiske tests Idriftsættelse og typiske fejl Første projekt kørt med TDD Opgaven Forudsætninger Fremgangsmåden Udviklingsmiljøet Design af servicelaget Udviklerens fremgangsmåde Behov for tools til understøttelse af TDD Kode statistik Erfaringer Interview med udviklere Råd til fremtidige projekter Konklusion Referencer

3 Bilag 1: Test-klassen StackTest Bilag 2: Implementation af Stack Bilag 3: Anvendelse af NMock Bilag 4: CruiseControl fejlet build Bilag 5: CruiseControl test-resultater Bilag 6: CruiseControl test-timing Bilag 7: Code Coverage Report Bilag 8: Spørgeskema til TDD-udviklere

4 1. Indledning Denne rapport er udarbejdet i foråret 2005 i forbindelse med Hovedopgaven på Diplomuddannelsen i Informationsteknologi (Softwarekonstruktion) ved Aarhus Universitet. Rapporten omhandler emnet Test Driven Development (TDD) og anvendelsen af TDD i et konkret projekt. Erfaringerne fra projektet indikerer at TDD fører til færre fejl i koden. Udviklerne mener, at de får en øget selvtillid og en større programforståelse. Man får også en bedre kodekvalitet, men udviklingstiden er til gengæld længere, end hvis man ikke anvendte TDD. En vigtig faktor for et succesfuldt TDD-projekt er værktøjer, der understøtter udvikleren i hele TDD-processen. 2. Motivation Test af software har altid været et interessant emne for mig. I forbindelse med mit arbejde som webudvikler i Jyske Bank har jeg prøvet flere teknikker med forskelligt udbytte. På JAOO 2004 konferencen i Århus fulgte jeg et spor omkring Test Driven Development (TDD), og det var for alvor med til at vække interessen for TDD. På konferencen holdt en af personerne bag NUnit[9], James Newkirk, et indlæg om TDD samt en heldags TDD-tutorial. Da vi i min afdeling i Jyske Bank stod overfor at opbygge en ny udviklingsplatform med Microsoft s.net teknologi, fandt vi at det var en god ide at afprøve TDD i et af de første projekter vi kørte. Der er gennem de seneste år lavet flere forsøg på at måle effektiviteten af TDD, og det har givet forskellige resultater. Det er ikke nogen nem opgave. Det giver ikke altid giver et klart svar, at måle effektiviteten af en udviklingsmetode. Denne rapport skal ses som et erfarings-input i forbindelse med vurderingen af TDD. 4

5 3. Problemformulering Udgangspunktet for denne opgave er Test Driven Development (TDD). En af guruerne inden for TDD Kent Beck[3], er kommet med denne hypotese: TDD giver: - Færre fejl. - Mindre debugging. - Mere selvtillid hos udviklerne. - Et bedre design. - Højere produktivitet. Til denne hypotese vil jeg frem komme med et datapunkt. Det gives i form af en evaluering og rapportering af vores (Jyske Banks) anvendelse af TDD i et konkret projekt. Der ud over vil jeg komme med en opsummering af nogle af de forsøg og eksperimenter omkring TDD, der er lavet de seneste år. 5

6 4. Relateret arbejde De seneste år er der udført flere forsøg og studier af effektiviteten af TDD i praksis. Her er et udpluk af nogle af dem: 4.1 Müller et al [5] I 2001 lavede Müller et al [5] et eksperiment, der sammenligner test-first programmering med traditionel udvikling. I test-first programmering laver man tests før implementation ligesom i TDD. Specielt skulle test-first programmeringsindflydelsen undersøges på programmerings-hastigheden, på program-pålideligheden og på program-forståelsen. Eksperimentet blev udført af 19 studerende, som var delt op i to grupper: Eksperiment-gruppen, der anvendte test-first og en kontrolgruppe, der anvendte traditionel udviklingsmetode. Begge grupper bestod af studerende på et Extreme Programming kursus på Computer Science Department ved University of Karlsruhe på 6. semester. Opgaven var udvikling af main klassen til et graph libary kun indeholdende metode-deklarationer. Resultat viste, at test-first ikke førte til hurtigere implementation og heller ikke til mere pålidelige programmer. Men det tyder dog på en bedre programforståelse blandt test-first udviklerne. De peger selv på manglende test-first erfaring blandt udviklerne som en mulig årsag til resultatet. 4.2 George et al [6] George et al [6] lavede et eksperiment for at afprøve hypoteserne: - TDD giver bedre kodekvalitet sammenlignet med kode udviklet med traditionel vandfalds metode. - TDD-programmører vil udvikle kode hurtigere end programmører, der benytter traditionel vandfaldsmetode. 24 professionelle programmører fra 3 virksomheder deltog. På hver virksomhed blev de delt op i tilfældige grupper med to i hver. Dvs. 6 TDD-grupper og 6 kontrolgrupper. Kontrolgruppen udviklede efter traditionel vandfaldsmetode (design, implementation, test og debug). De 24 programmørers erfaring varierede fra begynder til ekspert. Resultaterne viste: - Højere kvalitet i TDD-gruppernes kode. TDD-koden bestod 18% flere black box tests (software-testtype, hvor testeren ikke kender det, han skal teste, men kun input-muligheder og forventet output). - TDD-grupperne brugte i gennemsnit 16% mere tid til udviklingen. Erfaringerne med TDD viste også: - Testene fra TDD er værdifulde for produktets livsforløb, når produktet videreudvikles. - Koden, der udvikles er testbar. - Gennemtestet kode, afleveret til en kunde, er af højere kvalitet. Dette reducerer omkostningerne til testning hos kunden. 6

7 4.3 Kaufmann et al [7] Et andet eksperiment lavede Kaufmann et al [7] i Her blev påstandene om, at TDD øger softwarekvalitet og programmørselvtillid undersøgt. To grupper med 4 studerende i hver deltog. De studerende var alle Computer Science masterstuderende med programmeringserfaring i C++. Den ene gruppe anvendte TDD, og den anden gruppe var kontrolgruppe, der anvendte test-last programmering (lav implementationen først og derefter tests). Antallet af linier i koden og implementeret funktionalitet indikerede, at TDD-gruppen var mere produktiv: - Gruppen producerede 50% mere kode end test-last gruppen. - Analyse af koden indikerede flere designproblemer i test-last gruppens kode. Programmør-selvtilliden blev målt ved hjælp af et spørgeskema. På en skala fra 1 til 5 hvor 5 er mest selvtillid lå TDD-gruppen på 4,75 mod 2,50 i test-last gruppen. Der var nogen usikkerhed i eksperimentet, da den gennemsnitlige programmeringskarakter i TDD-gruppen var en hel karakter højere end i test-last gruppen. TDDgruppen bestod af studerende med længere tids studie bag sig end test-last gruppen. Den mulige større programmerings-erfaring kan have været med til at øge produktiviteten og selvtilliden samt til at give et bedre design. Kaufmann et al [7] vil derfor ikke konkludere, at TDD var grunden til at TDD-gruppen klarede sig bedst, men opfordrer i stedet til et større eksperiment med flere deltagere, der alle har samme programmerings-erfaring. 4.4 Williams et al [8] Hos IBM lavede Williams et al [8] et forsøg med at afprøve TDD. Man undersøgte TDD s indvirkning på fejlrater i softwaren og programmørernes effektivitet. Programmørerne var en gruppe fra IBM, der udviklede missions-kritiske systemer, som krævede høj availability, correctness og reliability. Man brugte udviklingen af en 7. version software til en gammel platform som kontrolgruppe (5 udviklere, der udviklede efter traditionelle metoder) og udviklingen af en 1. version software til en ny platform, som TDD-gruppen (9 udviklere). Ingen i TDD-gruppen havde arbejdet med TDD før. Man anså understøttelse af TDD i værktøjerne og programmørernes arbejde som en vigtig faktor for et godt resultat. Resultaterne viste: - Koden udviklet med TDD havde 40% færre fejl (målt i fejl pr liniers kode). - Fejlenes alvorlighed var stort set ens i de to grupper (lidt flere alvorlige fejl i kontrolgruppen) - Effektiviteten i de to grupper var ens. TDD-gruppen brugte mere tid på at skrive tests, men reducerede til gengæld tiden, der blev brugt på debugging. - TDD-gruppen lavede liniers programkode og liniers testkode (ca. 0,5 liniers testkode til hver linie programkode). - Udviklerne var meget positive overfor TDD-metoden og fortsatte efterfølgende med at bruge den. 7

8 4.5 Opsummering At lave forsøg, der skal måle kvalitet og effektivitet af anvendelsen af TDD og traditionelle udviklingsmetoder, er ikke nemt. Bare det at finde en forsøgsgruppe og kontrolgruppe med lige meget erfaring i den metode, der skal anvendes er svært. Forsøgene er alle udført på forskellige måder, af enten studerende eller af professionelle. Anvendelsen af TDD og understøttelsen af TDD i værktøjer er forskellige og/eller kun beskrevet overfladisk i forsøgene. Erfaringen med TDD inden forsøgene gik i gang har også været meget forskellig. Det giver alt sammen nogen usikkerhed i en samlet konklusion på forsøgene. Men hvis man skal prøve, at samle resultaterne, så indikerer de følgende om TDD: - Højere kvalitet i koden. - Færre fejl i koden. - Samme udviklingstid som traditionelle udviklingsmetoder. - Øget programforståelse og selvtillid blandt programmørerne. Efter afslutningen af de forskellige forsøg skrev man en konklusion på anvendelsen af TDD i udviklingen af systemerne. Man har derfor ikke fået undersøgt effektiviteten af TDD over systemernes samlede levetid. En af fordelene ved de automatiske tests er, at de gør det sikrere at lave rettelser og tilføjelser til et system, fordi man har de automatiske tests til at verificere, om en rettelse eller tilføjelse har tilført nye fejl i den eksisterende kode. 8

9 5. Test Driven Development Test Driven Development(TDD) er en software-udviklingsmetode, der har været anvendt i årtier. Metoden er senest blevet en central del af Extreme Programming (XP) [4], hvor TDD er med til at understøtte XP-udvikleren med øjeblikkelig feedback på hans arbejde. TDD er en af de teknikker i XP, der kan udføres alene, men den indeholder også andre XP-teknikker som: - Ingen dubleret kode (once and only once). - Refactoring. - Continuous integration. Becks [3] formulering af TDD s mål er Clean code that works, hvor Newkirk et al [2] har et lidt andet synspunkt. Nemlig, at hovedformålet i TDD ikke er test af software (det er en sideeffekt), men derimod en hjælp til udvikler og kunde i udviklingsprocessen med at fastlægge krav til softwaren. Krav til softwaren er udtrykt i form af tests, som er med til at understøtte udvikleren i sit arbejde. 5.1 Proces og metode Beck opstiller disse regler for TDD: - Skriv aldrig en enkelt linie kode, med mindre man har en fejlet automatisk test. - Fjern dublering i koden. I TDD tester man programmet, før man skriver det. I princippet skriver man aldrig en linie kode, uden man har en fejlet automatisk test. Det er dog i praksis ikke altid muligt at skrive test til alt. Test skal afspejle krav til koden. Derfor, har man ingen krav (tests), så har man heller ingen kode. Den anden regel siger, at ingen kode bør være dubleret i programmet. Dubleret kode fører nemlig til dårligt design, inkonsistens og mindre tillid til koden, især når folk glemmer, hvor dubleringen er. Udvikleren skriver selv sine unit-tests og skal derfor ikke vente flere timer på, at en eventuel test-afdeling får testet hans kode. De funktionelle- eller accept-tests skrives normalt ikke af udvikleren, men er kundens måde at sikre sig, at programmet gør som forventet set fra brugerens synsvinkel. Disse kan også være unittests, men typisk laves de med et andet værktøj Testliste Beck [3] beskriver en testliste, der er god at starte med, når man går i gang med en ny opgave eller en ny feature. Man starter med at udfylde en testliste. Listen er en brainstorm over alle de tests, man kan skrive til den kode man skal i gang med. Listen danner således en kravspecifikation til den Koden. Man udvælger en test fra listen og går i gang. Der findes flere teorier til udvælgelse af en test. Det kunne være en meget simpel test for bare at komme i gang. Det kunne også være en test, der arbejder med kernen af programmet eller bare tests fra toppen og ned efter på listen. Man overstreger tests på listen efterhånden som de er afsluttet, og når listen er udtømt er man færdig. 9

10 5.1.2 Red/Green/Refactor Red/Green/Refactor er processen for implementering af en test. Red er farven for en test, der er fejlet, og green er farven for en test, der er kørt igennem uden fejl. Refactoring er at forbedre koden uden at ændre på funktionalitet. Det er en vigtig del af TDD, da tilføjelse af tests kræver design (ændring af kode). Processen for implementering af en test er følgende: - Skriv testen - Compile test -> Red: fejl (ingen implementation) - Implementer nok til compile - Kør test -> Red: fejl - Implementer nok til Green - Kør test -> Green: OK - Refactor Fjern duplication - Næste test På den måde arbejder man sig frem i små skridt, og får feedback hver gang man kører tests. Med små skridt er det nemmere at finde de fejl, man laver, da man hele tiden kun har lavet få ændringer mellem hver test-kørsel. Man bruger typisk mere tid på tests end på implementering. En anden måde at se processen på giver Newkirk[1]: - Make it fail - skriv ikke kode uden man har en fejlet test. - Make it work - så simpelt som muligt. - Make it better - refactor. Bech[3] skriver om flere strategier for hurtigt at få en grøn bar: - Fake it (till you make it). Returner en konstant, der senere laves om til en variabel i den endelige kode. - Lav den oplagte implementation. Lav den endelige løsning med det samme TDD eksempel Newkirk et al [2] bruger en stak, når de skal lave et eksempel med TDD. En stak er en struktur, der giver adgang til det øverste element på stakken. En stak har typisk metoderne Push (nyt element på stakken), Pop (returner øverste element) og IsEmpty. En testliste (ikke komplet) kunne indeholde følgende tests: - Opret stakken og verificer, at den er tom. - Push et element og verificer, at stakken ikke er tom. - Push et element og pop det igen og verificer, at stakken er tom. Lad os starte med den første test og følge Red/Green/Refactor -processen. Her er test-klassen skrevet i C# med NUnit [9] (xunit, der er blevet en de facto standard for test-arkitektur): using System; using NUnit.Framework; namespace TestApplication{ 10

11 [TestFixture] public class StackTest{ [Test] public void Empty(){ Stack stack = new Stack(); Assert.IsTrue(stack.IsEmpty); [TestFixture] og [Test] er custom attributter i C# og bruges af NUnit. De betyder test-klasse og test-metode. Koden kan endnu ikke kompileres, da Stack ikke findes endnu. Næste skridt er implementation af tilstrækkelig kode til, at der kan kompileres. Så her laver vi Stack klassen: using System; namespace TestApplication{ public class Stack{ private bool isempty = true; public bool IsEmpty{ get{ return isempty; Skulle man følge TDD til det yderste, så skulle IsEmpty bare returnere true (Fake it), da det er nok til at få den første test til at køre igennem. Testen køres så i NUnit og giver en grøn bar. Testen streges på testlisten og næste test kan påbegyndes. Push et element og verificer, at stakken ikke er tom: [Test] public void PushOne(){ Stack stack = new Stack(); stack.push("element 1"); Assert.IsFalse(stack.IsEmpty); For at få testen til at kompilere, skal Push() i Stack-klassen se således ud: public void Push(Object element){ Testen fejler, da isempty ikke bliver sat til false, når man kalder Push(). Push ændres til: public void Push(Object element){ isempty = false; 11

12 Nu kører testen igennem. Næste skridt efter Green er refactor, og i vores testklasse har vi dubleret kode. Oprettelsen af stack er den samme kode i begge testmetoder. Det kan samles i en Init() metode: private Stack stack; [SetUp] public void Init(){ stack = new Stack(); [SetUp] køres altid før NUnit kører en testmetode. Derfor bliver der oprettet et nyt Stack-objekt til hver test. Der findes også en [TearDown]-metode, der køres efter hver test. Her kan man frigive ressourcer og lignende. Således kan vi fortsætte med test efter test, indtil vores testliste er opbrugt og opgaven udført. Den samlede kode med den tredje test kan ses på bilag 1 og 2. Laver man lidt statistik på koden, giver det dette resultat: Implementation Tests Klasser 1 1 Funktioner 3 4 Linier Linier / funktioner 7 9 Asserts 0 3 Selv i dette meget lille eksempel viser det sig, at der er mere kode i testene end i selve implementationen. 12

13 5.2 Patterns og tips TDD handler meget om design, der både skal være simpelt og testbart. Ud over de kendte design-patterns fra Gang Of Four, findes flere design-patterns, teknikker og tips til TDD-udvikleren. Her er nogle af dem fra Newkirk et al [2] og Beck[3], som jeg finder mest nyttige The 3A Pattern The 3A Pattern er det mønster, man typisk følger når, man skriver tests: 1. Arrange Oprettelse af objekter, der skal bruges i testen. 2. Act Lad objekterne udføre det arbejde, der skal testes. 3. Assert Verificer resultatet af testen med det forventede resultat Isolated test Når man kører flere tests, må de ikke kunne påvirke hinanden. Hvis en test fejler, må den ikke efterlade systemet i en tilstand, der får næste test til at fejle. En fejlet test skal afspejle et problem i systemet. To tests, der fejler, skal afspejle to problemer i systemet osv Learning Test Når man vil anvende eksternt udviklet software, er det en god ide at skive test til den del, man vil anvende. Man lærer at benytte softwarens API, og når der kommer en opdatering til softwaren, kan man køre sine egne tests. Fejler de, så vil koden, der benytter den eksterne software heller ikke virke Mock Object Når man skal teste et objekt, der afhænger af en dyr eller kompliceret ressource, kan et mock-objekt, der er en simuleret udgave af ressourcen, bruges. Mockobjekter benyttes typisk, når man tester objekter, der tilgår databaser. Her er man interesseret i at teste objektet og ikke tilgangen til databasen. Mock-objekter giver også en hurtigere afvikling og mere stabile tests. For at kunne skifte mellem et mock-objekt og det rigtige objekt, kræves der en mindre kobling i designet Crash Test Dummy Man kan tit glemme at teste fejlhåndtering i eksempelvis try-catch blokke. En måde at teste fejlhåndtering på, er at lave et specielt mock-objekt (crash test dummy), der ikke udfører det forventede arbejde, men kaster exceptions i stedet for. Har man et objekt, der bruger et File-objekt til at læse en fil, laver man en mock-udgave, der nedarver File og altid kaster exceptions i de metoder, der har throw i metodesignaturen. 13

14 5.3 TDD afsluttende bemærkninger Ikke alle typer software er lige nemme at skrive test til. Sikkerheds-software og concurrency er to områder, hvor TDD er særdeles svær at anvende. Test af GUI elementer kan også være svært. Til at skrive test til websider lavet i ASP.NET (kun code-behind) findes der NUnitAsp [10], som er en tilføjelse til NUnit. Test af sikkerheds-software, concurrency og GUI elementer vil jeg dog ikke komme mere ind på i denne rapport. Testene er ikke kun værdifulde, mens man udvikler. De er også en slags kørende dokumentation af ens kode. Når man på et senere tidspunkt skal lave en udvidelse eller rettelse til koden, har man de kørende test til at verificere, at man ikke ødelægger eller ændrer eksisterende funktionalitet uden at opdage det. Hvis man skal i gang med implementering af TDD i kode, hvor der ikke er tilstrækkelige tests, er der ikke andet at gøre end at skrive de tests, der mangler. Ellers risikerer man at ødelægge noget under refactoring. Problemet kan dog være, at koden ikke er designet til test TDD og The Scientific Method Mugridge [11] har undersøgt TDD og The Scientific Method og fundet frem til, at The Scientific Method kan bruges til bedre at forstå TDD og omvendt. Hovedelementerne i The Scientific Method er: - Gentagende eksperimenter bruges til at teste påstande i en teori. Et eksperiment har tilknyttet kontrol eller verifikation. - Teori udvikler sig gennem små og store ændringer. Tests i TDD har rollen som eksperimenter, og design har rollen som teori, og gentagende eksperimenter udføres med gentagende kørsel af automatiske tests, der bekræfter at teorien (designet) ikke er ændret eller ødelagt. Programmets teori udvikles gennem eksperimenter (tests). Teorien forfines til at passe til tests gennem refactoring. Mugridge ender med at konkludere, at der specielt er en sammenhæng mellem TDD og The Scientific Method, når man ser på udvikling af en teori og reproducering af videnskabelige eksperimenter. Den stærke sammenhæng indikerer, at traditionelle udviklingsmetoder sammenlignet med TDD er mangelfulde. 14

15 6. Traditionelt web-projektforløb i Jyske Bank Strategien for decentral udvikling (applikationer, der ikke kører på den centrale mainframe) i Jyske Bank siger, at al decentral udvikling skal laves i programmeringssproget Java, dog med undtagelser i tilfælde, hvor andre teknologier er oplagte. Dette kunne være udvidelser til Office-pakken, udvikling til specialhardware (PDA osv.), til købesystemer eller lignede. Men af historiske årsager er der lavet en del webudvikling på Microsoft-platformen (ASP, COM, ASP.NET, SQL Server). Da man i sin tid skulle udskifte den gamle Notes-platform valgte man Microsoft-platformen til det, vi kalder reklame-websites (typisk websites med lidt forretningslogik), blandt andet fordi Java-platformen ikke var helt klar på dette tidspunkt. Da det første website blev udviklet, blev der også lavet et Content Management System (CMS) til at lægge indhold ind på websitet. CMS en blev lavet som et website, med mulighed for oprettelse af dokumenter, import af filer, publiceringsrutiner, rettighedsstyring osv. Som tiden gik, kom der flere websites til systemet, og i dag er der 7 eksterne og 2 interne af koncernens og datterselskabers websites i systemet. Hele systemet bliver i daglig tale kaldt JyskeSites. Ansvaret for de 9 websites og CMS en ligger fordelt på 3 afdelinger (med ca. 16 udviklere, der arbejder med systemet), og der er typisk 3-4 projekter eller opgaver i gang med at lave nye websites, opdateringer, optimeringer eller vagtopgaver. Koden er opdelt således: - Specifik ASP (Microsoft s Active Server Pages) kode på hver website. - Fælles ASP-kode inkluderet på hvert website. - Fælles COM (Common Object Model) kode skrevet i Visual Basic kørende på Microsoft Transaction Server (MTS), der tilgås fra ASP. - Fælles Stored Procedure på SQL Server, der tilgås fra COM. Det betyder, at når man ændrer i fælles kode, kan det have indvirkning på alle websites, og de bør derfor testes, inden man sætter ændringen i produktion. Et typisk projektforløb løber over 3-6 måneder, hvor der udvikles iterativt med iterationer på ca. 14 dage. Man burde sætte det, man har lavet i en iteration i produktion umiddelbart der efter, men af praktiske årsager er det besluttet, at der sættes i produktion en gang hver måned. Dels fordi det er en tidskrævende opgave, og dels pga. den stærke kobling, der er i koden, der betyder, at man ikke kan sætte ændringer i produktion alene til et website. Der er typisk ændret i den fælles kode, og der er ændringer, som derfor kan påvirke de øvrige websites i systemet. 15

16 6.1 Brugen af automatiske tests Brugen af tests er på klient-siden, hvor vi har lavet et test-værktøj, der kan teste websites med VBUnit (Unit Test Framework til Visual Basic og COM objekter) og et Internet Explorer objekt. Udviklerne skriver tests i et XML-format, der afvikles mod brugergrænsefladen. Mulighederne i testværktøjet er blandt andre: - Naviger til en URL (med verifikation af, at det går godt). - Klik på et link, billede, knap eller andet et element (med verifikation af, at der sker en navigation). - Submitte en form (med verifikation af, at der sker en navigation). - Klikke på et element uden, at der sker en navigation (et click-event). - Sætte fokus på et element. - Sætte fokus på en frame. - Sætte værdier i alle typer input-felter. - Enable og disable elementer. - Verificerer, at en bestemt tekst findes eller ikke findes på siden. - Verificerer værdier i alle typer inputfelter. - Verificerer sidens titel. - Mulighed for at give Java script kommandoer, der skal afvikles under testen. - Udskrivning af værdier. Det kræver, at man har lavet en testbar HTML-kode med navn og id på de HTMLelementer, som man vil teste. Derudover er det særdeles vanskeligt at skrive test til webapplikationer, der benytter Java Script menuer, modeless dialog boxes eller Java Applets. Vi har også lavet forsøg med at skrive VBUnit-tests til COM-objekterne, men det er aldrig rigtig slået igennem og bruges ikke pt. En af grundene er, at det er vanskeligt at afvikle COM-objekterne lokalt. Lokale forhold kan være opsætning af COMobjekter, afhængigheder mellem COM-objekterne og databaseadgang. 16

17 6.2 Idriftsættelse og typiske fejl Når der sættes i produktion, køres ændringer fra versionsstyrings-værktøjet (Microsoft Visual Source Safe single checkout mode), først på et test-miljø hvor brugere og udviklere har 3 dage til at teste og rette fejl inden der sættes i produktion. I den forbindelse køres alle brugergrænseflade-tests før og efter der køres ændringer på test-miljøet (for at være sikke på om det er ændringerne, der har fået tests til at fejle) og resultatet sendes til alle udviklere. Samme procedure køres når der sættes i produktion, her med udviklere på sidelinien klar til at se på fejl og problemer med det samme. Erfaringerne viser at brugergrænsefladetestene og den manuelle-test ikke fanger alle fejl inden de kommer i produktion. Der er således næsten altid travlt, med at rette små og store fejl, i dagene efter der er sat i produktion. Det er langt fra tilfredsstillende og slet ikke for driftselskabet, der får nok at se til. De typiske fejl er: - Ændringer i den fælles kode. Der er en høj binding i koden og lav modificerbarhed pga. meget fælles kode og mange includes (ASP-sider der inkluder en eller flere ASP-sider, der igen kan inkludere andre ASP-sider). Alt sammen noget, der ikke er et værktøj, der kan hjælpe med at holde styr på. En ændring kan således påvirke ganske mange andre sider. - Fejl der kunne opdages med brugergrænsefladetests, men der ikke er skrevet tests til. Der er ca. skrevet test til 25-50% af systemet. - Fejl der kun opstår i produktionsmiljøet. Da de ikke opstår i testmiljøet pga. et testmiljø der ikke afspejler produktionsmiljøet 100%. Systemet og udviklerne kunne således godt bruge nogle af de fordele, som TDD skulle give ifølge Beck, især: - Færre fejl. - Mere selvtillid hos udviklerne. Så man tør rette i kode og kan se om man ødelægger noget. - Et bedre design. Men ASP og COM-setup et er ikke umiddelbart oplagt til TDD pga. kodens struktur og systemets design. 17

18 7. Første projekt kørt med TDD I dette afsnit vil jeg komme ind på de erfaringer og resultater, samt fremgangsmåde og anvendelse af værktøjer, vi fik fra det første projekt hvor vi har anvendt TDD. 7.1 Opgaven Projektet skulle lave et servicelag til Jyske Bank s Content Management System (CMS). Servicelaget skulle bestå af en række webservices, der tilsammen kan levere indhold som dokumenter, filer, menustruktur og komponentbokse (grafer, kurslister, links) til et helt website. De eksisterende websites der benytter CMS en har alle en tæt binding til CMS en gennem fælles kode (ASP, COM og SQL). Det er strategien at fremtidige websites skal udvikles i Java. Der er derfor brug for at afkoble dem fra CMS en med servicelaget som en grænseflade til CMS en. Det er vedtaget at CMS en skal videreudvikles i Microsoft.NET og servicelaget var således det første.net projekt i den forbindelse. Så udover selve produktet skulle projektet også etablere en.net udviklingsplatform til webudvikling. Det var et ønske, at udviklingen af servicelaget kunne blive drevet af en business case, der kunne stille krav til og bruge servicelaget. Men det var desværre ikke muligt. I stedet for blev projektet bedt om at medvirke til proof of concept i forhold til en eventuelt anvendelse af IBM Websphere Portal Server (WPS) i Jyske Bank. Projektet skulle være med til at afklare, hvordan WPS kan anvende indhold fra CMS en. Derudover valget vi selv at lave et test-website, der skulle bygge på data fra servicelaget. 7.2 Forudsætninger Projektgruppen bestod af 5 udviklere: - 3 fra afdelingen der har ansvaret for CMS en og dermed servicelaget. - 2 fra 2 forskellige afdelinger, der laver systemer, som anvender CMS en. Alle udviklere havde noget erfaring med udvikling i.net. Det var erfaring opbygget i forbindelse med uddannelse, små opgaver og andre projekter. Alle havde en datamatiker-uddannelse eller højere og ca. 1 til 5 års erfaring med webudvikling. Derudover erfaring med OO udvikling, teknikker fra Extreme Programming (XP), unit-testing i mindre grad og TDD på et teoretisk niveau. 4 af projektdeltager deltog inden sevicelag-projektet i projektet.net udviklingsplatform og var i den forbindelse på flere.net kurser og arbejde med værktøjer, standarder, anbefalinger og best practices for den fremtidige anvendelse af.net i Jyske Bank. Her havde vi også en demonstration af TDD i praksis. I starten af servicelag-projektet snakkede vi om at afprøve TDD i projektet. Tidligt i projektforløbet var vi to udviklere på JAOO 2004 i Århus. I den forbindelse hørte vi flere TDD-indlæg og fulgte en TDD-tutorial. Da vi kom tilbage var vi sikker på, at det skulle afprøves og måske være en del af den fremtidige udviklingsplatform (her tænkes mest på support til TDD i form af værktøjer). Vi fik de øvrige udviklere med på ideen og repeterede TDD-teorien for projektgruppen. 18

19 7.3 Fremgangsmåden Første skridt var opsætning af et brugbart udviklingsmiljø, der henover projektforløbet blev forbedret med diverse tools til understøttelse af TDD. Efterfølgende begyndte arbejdet med det overordnede design af servicelaget. Og derefter selve udviklingen Udviklingsmiljøet Da der ikke var lavet et færdigt udviklingsmiljø til webudvikling i.net, var det første opgave i projektet. I det gamle ASP og COM miljø bliver der udviklet fra en lokal arbejdsplads, hvor koden bliver gemt på en fælles udviklingsserver. Her kan den udviklede kode testes. Debugging er således kun muligt på serveren og vil stoppe al brug af testserveren, for de andre udviklere, af samme grund bliver det stort set ikke anvendt. Det var derfor et ønske, at kunne udvikle og teste lokalt i det nye.net miljø, samtidig med en fælles udviklingsserver skulle være tilgængelig for alle, til yderligere testning på en server med samme konfiguration som produktionsserverne. Vi satte udviklingsmiljøet op i Isolated mode, udvikleren kunne så udvikle, debugge og afvikle kode lokalt på en lokal webserver. Databasen blev ikke lagt lokalt, da databasen til systemet i øjeblikket fylder over 4 GB og arbejdet med at holde de lokale databaser opdateret ville blive alt for stort. I stedet for blev den fælles udviklingsdatabase anvendt. I første omgang var det også planen, at benytte de gamle COM objekter fra.net koden, så de blev også installeret lokalt. Men det viste sig hurtigt at give mange problemer med opdatering af COM-objekter lokalt og performance-problemer i wrapping mellem COM og.net. Så anvendelsen af COMobjekterne blev skrevet ud af koden igen. Koden blev gemt i versionsstyringsværktøjet MS Visual Source Safe (single checkout mode), der integrerede med udviklingsværktøjet (MS Visual Studio.NET 2003). Til at opdatere den fælles udviklingsserver blev server-produktet CruiseControl.NET (CCNet) fra ThoughtWorks anvendt. CCNet er en automatisk continuous integration server til.net platformen. CCNet kan monitorere et område i versionsstyringsværktøjet og når der er tilføjet ændringer, laver CCNet en ny build af projektet eller en hel solution. Der er også mulighed for integration med tools som NUnit og NCover (NCover kan hjælpe med at finde områder i koden, der ikke bliver testet). 19

20 7.3.2 Design af servicelaget Servicelaget skulle returnere data fra CMS-systemet via webservices. Vi lavede derfor først en objektmodel med de DTO-objekter (Data Transfer Object), der skulle bruges til at returnere data fra CMS-systemet. Med inspiration fra Newkirk et al [2] Service Layer endte vi op med det design, som kan ses på Figur 1: Servicelag pakkediagram. Figur 1: Servicelag pakkediagram. Her er en kort beskrivelse af de enkelte pakker: WebService-pakken indeholder de webservices, der stilles til rådighed for klienten og er således klientens serviceinterface til Servicelaget. Der er ikke lavet tests til denne pakke, da den kun indeholder en webservice med flere metoder, der benytter Corepakken. Der er ikke mere funktionalitet i metoderne end i de tests, der er skrevet til Core-pakken. MailService-pakken indeholder funktionalitet til håndtering af til- og framelding til mailservices. Funktionaliteten kunne have været placeret i Core-pakken, men fik sin egen pakke, da vi gerne ville adskille mailservice-funktionalitet fra den øvrige CMSfunktionalitet i systemet. Core-pakken er kernen i systemet og indeholder de databærende DTO-klasser. Der ud over indeholder pakken Assembler-klasser. Assembler-klasserne kaldes fra WebService-pakken og opbygger DTO-objekter ud fra de data de får fra DataAccess- 20

21 pakken, DTO-objekterne returneres til WebService-pakken, der returnerer dem til klienten. DataAccess-pakken indeholder service-klasser, der henter data fra databasen. Service-klasserne implementere et service-interfrace, så Assemblerne-klasserne fra Core-pakken ikke er bundet til dem. Det giver den fordel at de enkelte lag kan testes uafhængigt af hinanden. DataSets-pakken indeholder Typed DataSets, der er autogeneret af udviklingsværktøjet ud fra de stored procedures, som kaldes i databasen af DataAccess-pakken. Pakken er oprettet for at isolere den autogenerede kode i sin egen pakke. Der er derfor ikke skrevet tests direkte til pakken. Men datasets ene bliver anvendt i de tests, der er skrevet til Core- og DataAccess-pakkerne. AdminTools-pakken indeholder forskellige administrative-værktøjer og er ikke udviklet efter TDD. Test-pakken indeholder de automatiske unit-tests, der er skrevet til de enkelte klasser og er opdelt i en struktur efter de pakker, med underliggende klasser, der testes. Vi har således lavet et lagdelt og testbart design, hvor det er muligt at afvikle tests mod et enkelt lag. En fejl i DataAccess-laget vil ikke få tests i core-laget til at fejle, hvordan det er lavet kommer jeg ind på i næste afsnit Udviklerens fremgangsmåde Den typiske fremgangsmåde for TDD-udvikleren i projektet endte med at være følgende: 1. Start udviklingsværktøjet op og åben en solution, der indeholder alle projekter (pakker). 2. Hent nyeste kode fra versionsstyringsværktøjet. 3. Lav en build af koden. 4. Kør alle tests med NUnit og verificer, at de ikke fejler. 5. Så er man klar til at udvikle og arbejder efter TDD metoden. 6. Når man er færdig med koden, laver man en ny build. 7. Kør alle tests med NUnit og verificer, at de ikke fejler. 8. Commit de færdige ændringer til versionsstyringsværktøjet. For at det gik godt, havde vi nogle retningslinier vi arbejde efter: - Ret eventuelle fejl før man går i gang med nyudvikling. - Commit aldrig ændringer til versionsstyringsværktøjet, hvis man har en fejlet test. - Når man begynder på en ny klasse oprettes der en tilsvarende test-klasse i test-pakken. Afviklingen af tests skete med NUnit s GUI, som ses på Figur 2: NUnit GUI, hvor testene under Core.Util (Util indeholder forskellige små funktioner, bl.a logging) er blevet kørt. Her er en enkelt test under ResourceReader fejlet. 21

22 Figur 2: NUnit GUI. For at kunne teste Assembler-klasser i Core-pakken isoleret fra databasen (uden at anvende DataAccess-pakken), anvendes DataAccess pakken ikke direkte, men i stedet for tager alle Assembler-klasser et objekt af typen service-interface med i constructoren. Det kunne eksempelvis være en instans af klassen DataAccess.DocListItemService, der implementere interfacet IDocListItemService, eller det kunne være et mock-objekt, der implementere interfacet IDocListItemService. Tests til Assembler-klasser benyttede således mock-objekter til implementere de service-interface Assembler-klasser skal bruge. Princippet for anvendelsen af database-mock er skitseret på Figur 3: database-mock anvendelse. DataAccess IDataService Mock IDataService Assemblerklasse Database Figur 3: Database-mock anvendelse. 22

23 Til at lave mock-objekter med, anvendte vi produktet NMock [12], der er et dynamisk mock-objekt, som kan anvendes til unit-tests i.net. Proceduren for anvendelse af NMock i en test er: - Setup af mock-objektet (hvilken type skal objektet være). - Forventninger til anvendelse af mock-objekt (hvordan forventer klassen der skal bruge mock-objektet at anvende det). - Oprettelse og anvendelse af klassen der skal testes. - Verifikation af mock-objektet blev anvendt som forventet. - Eventuelle asserts af klassen der testes. Et kode-eksempel på anvendelsen af NMock kan ses på bilag 3, hvor mock-objektet indeholder XML-strenge til at lave de DataSets, der skal returneres af mock-objektet. Da DataAccess-pakken tilgår databasen, er testene også afhængig af en kørende database. Det gav to typer af problemer, der udløste fejl i testene: - Hvis en bagvedliggende stored procedure blev ændret kunne det give en fejl i anvendelsen af de autogenerede DataSets, der så ikke længere passede til stored proceduren. Det var godt af fange den type-fejl, da de ellers ikke ville blive fundet af de øvrige tests. Fejlen blev løst ved at lave et nyt DataSet på baggrund af stored proceduren. - Den anden type fejl opstod pga. ændringer af data i databasen. De fleste tests til DataAccess-pakken skulle sende input-parametre med i testen, eksempelvis id-nummer på et dokument eller tekst-strenge der skulle søges efter. Hvis så dokumentet, man bruger i testen er blevet slettet eller ændret, kan eller vil testen fejle. Det var svært at sikre sig i mod, da der var mange udviklere der benyttede systemet og der jævnligt blev lagt en kopi af produktionsdatabasen på udviklingsmiljøet. Vi fandt dog en løsning der kunne bruges i de fleste tilfælde. I Testpakken oprettede vi en test-helper, der kunne bruges til at afvikle små sql-forespørgsler, til at finde data, som testene så kunne anvende til input i de klasser de testede. 23

24 7.3.4 Behov for tools til understøttelse af TDD Ud over udviklingsværktøjet og NUnit, endte vi med at anvende flere små tools til understøttelse af TDD. Som tidligere nævnt, blev CruiseControl.NET (CCNet) anvendt til at lave automatiske builds af koden. Det skete hver gang, der blev tilføjet kode til versionstyringsværktøjet, og automatisk en gang hver nat. Når der blev lavet en build på serveren, kompilerede CCNet koden og kørte alle tests (med NUnit), som en del af den samlede build. Hvis serveren skiftede status fra working (kompilering OK og alle tests kørt uden fejl) til broken (kompilering fejlet eller tests fejlede i build) eller omvendt, fik alle udviklere på projektet en mail om status-skiftet, samt detaljer om eventuelle fejl. På den måde var vi hele tiden opmærksomme på at vores aktuelle build var kørende. CCNet havde også et website på build-serveren, hvor man hele tiden kunne få forskellige informationer om projektet. De mest anvendte informations-sider var: - Projekt statistik, som kan ses på Figur 4: CruiseControl.NET project statistics. Vi mistede desværre statistik midt i projektet pga. opgradering til en ny version af CCNet. - Detaljer omkring alle builds, som kan ses på Bilag 4: CruiseControl fejlet build. - Detaljer omkring afviklede tests, som kan ses Bilag 5: CruiseControl testresultater. - Test-timing, der viser hvor lang tid hver enkelt test var om at blive afviklet, se Bilag 6: CruiseControl test-timing. Figur 4: CruiseControl.NET project statistics. Til at hjælpe udviklerne med at se om alt kode i en klasse blev testet, anvendte vi NCover ( NCover måler hvilke dele af koden, der gennemløbes af tests. Resultatet kan bruges til at se om der er dele af koden der mangler at blive testet eller ikke bruges og derfor bør slettes. Vi anvendte NCover som den del af det build CCNet kørte. Resultatet kunne ses på CCNet-website på build-serveren, et eksempel kan ses på Bilag 7: Code Coverage Report. En ting man skal husk omkring code coverage, er at det kun måler gennemløb i koden og ikke om der bliver testet (lavet asserts). Så man kan altså ikke bruge code coverage til at se om man har lavet gode tests, men som et værktøj til udvikleren, der hjælper med ikke at glemme at teste hele koden. 24

25 Et andet nyttigt lille tool vi anvendte var TestDriven.NET ( som er et add-inn til udviklingsværktøjet Microsoft Visual Studio.NET. Med TestDriven.NET kan man med et enkelt klik få afviklet sine tests med NUnit. Mulighederne er mange bl. a.: - Afvikling af tests i consollen i værktøjet. - Afvikling af tests i debug-mode i værktøjet. - Afvikling af tests i NUnitGUI. - Klik på en test-metode, test-klasse, folder med test-klasser, projekt eller solution og kør dem med NUnit. Det sidste tool jeg vil nævne er CCTray ( der er et lille utillity, der ligger i Windows-tray. CCTray kobler op i mod CCNet så man kan hele tiden se status på projektet. CCTray-ikonet skifter farve efter build status på projektet på CCNet. Status den kan vise er: - Grøn seneste build er kørt med succes. - Rød seneste build er fejlet. - Grå ingen kontakt til CCNet. - Gul build i gang. Derudover kan man force en ny build, hvis man ikke vil vente på CCNet selv går i gang. Tool et var installeret på alle udviklernes maskiner og var med til at de til hele tiden fokusere på at have en kørende build. 25

26 7.4 Kode statistik Laver man lidt statistik på koden giver det følgende resultater, først delt op på de enkelte pakker og derefter en samlet statistik. Alt sammen målt i alle C# klasser, uden kodekommentar og interfaces. Statistik for Core-pakken: Implementation Tests Klasser 39 23(1) Funktioner Linier Linier / funktioner Asserts (1) Der er kun lavet tests til 7 ud af 22 Data Transfer Object (DTO) klasser, og ingen til 2 exception-klasser. DTO-klasserne er databærende klasser uden funktionalitet. Vi valgte derfor ikke at lave tests til dem alle sammen, da det føltes som spild af tid. Havde der være tests til dem, ville vi kunne se flere linier kode i testene end i selve implementationen. Statistik for DataAccess-pakken: Implementation Tests Klasser 14 9(1) Funktioner Linier Linier / funktioner Asserts 0 91 (1) Der er ikke lavet test til en ekstern database-komponent og de 4 sikkerhedsklasser den benytter til at læse en krypteret connectionstring til databasen med. Statistik for MailService-pakken: Implementation Tests Klasser 7 2(1) Funktioner Linier Linier / funktioner Asserts (1) Testene i pakken er samlet i to test-klasser. Statistik for den samlede kode: Implementation Tests Klasser Funktioner Linier Linier / funktioner Asserts Havde der været lavet tests til alle DTO-klasser, ville der havde været ca. lige meget kode i implementationen og test-klasserne. Alle tests kunne afvikles på sekunder, afhængig af maskinen de blev afviklet på. 26

27 7.5 Erfaringer TDD virker umiddelbart nemt at gå til, især når man ser eksempler som TDD eksempel, men når man har et lidt større system med web-services, GUI-elementer og eksterne ressourcer som databaser og filsystemet, så er der mange ting der skal tages hensyn til for at få et testbart design. Man er simpelthen nød til at lave et godt design, for at kunne teste de enkelte klasser afkoblet fra resten af systemet. Det er lykkedes for os at få systemet så afkoblet, at en fejl i koden kun giver en fejlet test. Gennem projektet udviklede systemet sig. Vi lavede om i designet flere gange i starten, for netop at kunne teste afkoblet. Der var meget som var nyt for os i projektet, det var det første.net projekt for flere af os. Havde vi haft mere erfaring med udviklingsplatformen, havde vi måske også lavet et bedre design fra starten. En ting der var svært fra starten af, var at tænke TDD når man udvikler. Man tog gang på gang sig selv i at lave implementation før man lavede tests. Som projektet skred frem benyttede vi flere tools til understøttelsen af TDD, dels for at gøre livet som TDD-udvikler nemmere og dels for at sætte fokus på tilstanden af systemet. Når en test på build-serveren fejlede, fik alle en mail hvor man kunne se beskrivelse af fejlen og hvem der havde tilføjet koden til versionsstyringsværktøjet og dermed startet en automatisk build. Derudover kunne man hele tiden se status på build-serveren i sin Windows tray. På den måde følte vi alle et fælles ansvar for hele tiden af have et stabilt og fejlfrit build i versionsstyringsværktøjet og på buildserveren. De automatiske tests, der blev skrevet til klasser i TDD-udviklingen, viste sig værdifulde, da de flere gange var med til at finde nye fejl, der blev introduceret under udviklingen i systemet. Når der skal videreudvikles på systemet i fremtiden vil de formodentligt også vise sig at være værdifulde, fordi man hele tiden har dem til at kontrollere at man ikke har ændret eksisterende funktionalitet uden at vide det. I den kode der blev sat i produktion blev der stort set ikke konstateret fejl. De typiske fejl var manglende opsætninger eller rettigheder på produktions-serverne. Hvis man prøver at sammenligne projektet og produktet med tidligere projekter og produkter udviklet til JyskeSites-systemet, har der været væsentligt mindre fejl og problemer. Jeg mener også kvaliteten og modificerbarheden er højere, da servicelaget er designet med en lagdelt arkitektur med lav binding mellem de enkelte lag. Vi registrerer desværre fejl i JyskeSites-systemet, så der findes ingen tal der kan bevise at der har været færre fejl. Det kan skyldes, at der er udviklet efter TDD, men der er også andre faktorer der er ændret i forhold til tidligere projekter: - Ny udviklingsplatform (.NET udviklet objektorienteret). - Første gang unit-test anvendes i stor stil. - Ingen rigtig kunde til systemet, kun test-applikationer så alle fejl er måske ikke opdaget endnu. 27

28 7.5.1 Interview med udviklere Jeg har lavet et spørgeskema omkring anvendelsen af TDD i servicelag-projektet, som de 5 deltagere har svaret på. Der er selvfølgelig nogen usikkerhed i resultatet, set i forhold til en generel vurdering af TDD, når målgruppen for spørgeskemaet er så lille og det kun er erfaringer fra et TDD-projekt der er undersøgt. Spørgeskemaet kan ses på Bilag 8: Spørgeskema til TDD-udviklere. Resultatet af spørgeskemaets enkelte spørgsmål er: A. TDD øger selvtilliden (man er ikke bange for at rette i kode, da de automatiske tests "opdager", de fejl man eventuelt introducere i koden). Meget uenig Uenig Hverken eller Enig Meget enig Ved ikke 0 % 0 % 0 % 40 % 60 % 0 % B. TDD hjælper med en mere effektiv debugging. Meget uenig Uenig Hverken eller Enig Meget enig Ved ikke 0 % 0 % 0 % 80 % 20 % 0 % C. TDD giver færre fejl. Meget uenig Uenig Hverken eller Enig Meget enig Ved ikke 0 % 0 % 0 % 60 % 40 % 0 % D. TDD giver en kortere udviklingstid. Meget uenig Uenig Hverken eller Enig Meget enig Ved ikke 20 % 60 % 20 % 0 % 0 % 0 % E. TDD giver en bedre kode kvalitet. Meget uenig Uenig Hverken eller Enig Meget enig Ved ikke 0 % 0 % 0 % 60 % 40 % 0 % F. TDD giver et mere simpelt design. Meget uenig Uenig Hverken eller Enig Meget enig Ved ikke 0 % 20 % 40 % 40 % 0 % 0 % G. TDD øger samlet set produktiviteten. Meget uenig Uenig Hverken eller Enig Meget enig Ved ikke 0 % 0 % 40 % 40 % 20 % 0 % 28

29 H. Hvad er din generelle vurdering af TDD? Udvikler 1: Hjælper til at der fra starten af fokuseres på det ønskede resultat af koden, frem for at man fokuserer på programmeringstekniske detaljer. Det hjælper til at man deler "opgaven" op i mindre overskuelige bidder - det gør at koden bliver mindre kompleks og derved nemmere at overskue både når den skal kodes første gang og ved evt. senere rettelser/videreudvikling. Udvikler 2: For at det skal fungere i et projekt er det nødvendigt at alle er comittet, ellers forsvinder tilliden nævnt i spørgsmål A hurtigt. Det kræver en ekstra indsats at designe ordentlige tests, når der fx er databaser, filsystemer, bugergrænseflader, webservices eller active directories involveret. TDD er en designaktivitet, der sikrer, at den kode, der bliver skrevet, faktisk kan testes. Hvis der findes kørende unittests til en komponent, er kaldene i unittestene også en god anvisning på, hvordan komponenten kan anvendes. TDD skaber dermed sin dokumentation i løbet af udviklingsprocessen. Udvikler 3: Det er en rar måde at arbejde på, men nogle gange gør man løsningerne mere kompliceret, for at gøre det mulig at teste koden. Under tidspres bliver ting der skulle være private til public, for at gøre det nemmere at teste. Udvikler 4: Efter lidt tilvænning så er TDD-metoden god. Generelt er udviklerne positivt indstillet overfor TDD og set i forhold til Kent Becks [3] hypotese omkring TDD (færre fejl, mindre debugging, mere selvtillid, bedre design og højere produktivitet), så holder punkterne i nogen grad: - Alle er enige om øget selvtillid. - Alle mener TDD giver færre fejl. - Alle mener TDD giver en bedre kode kvalitet. - Der er uenighed om TDD giver et mere simpelt design. - Alle er enige om TDD betyder længere udviklingstid, men på trods af det mener flertallet at produktiviteten bliver øget med TDD. 29