Halmstad Högskola
Sektionen för informatik, data och elektronik Kurs: C-uppsats 15 ECTS
Ämne: Informatik 61-90 Höstterminen 2008 Period 1-2
Effektiv applikationsutveckling med TDD – Test Driven Development
Abstrakt
Test Driven Development (TDD) är en utvecklingsteknik där testning ses som en naturlig del i utvecklingsprocessen och där tillvägagångssättet hjälper utvecklaren att sektionera upp programkoden till mindre och mer hanterbara delar. På så sätt ger TDD utvecklare ett stöd under programmeringsfasen så att de får fram ren och flexibel kod som är enkel att ändra och felsöka. TDD som teknik underlättar även möjligheterna att utveckla koden inom den tidsram som finns i och med att betungande testfaser, som i traditionella metodiker och tekniker kan bli tidsavgörande, istället integreras som en naturlig del i utvecklingsprocessen. Syftet med denna uppsats är att belysa de fördelar som finns med att använda TDD vid utveckling av nya applikationer. Vi ska ge utvecklarna som är involverade i programmeringsfasen argument till varför TDD bör tillämpas vid utveckling av applikationer och hur TDD kan vara ett hjälpmedel för att uppnå en bättre kodstruktur/design för applikationen. Vi gjorde undersökningen genom att ta fram teori inom området och utföra intervjuer baserade på den framtagna teorin. Efter att intervjuerna hade utförts, analyserades det material som framkommit. Slutligen presenteras ett antal viktiga argument kring varför de tillvägagångssätt som beskrivs inom TDD kan utgöra effektiviseringar under utvecklingsprocessen. Ett av argumenten är att användandet av omfaktorering ger utvecklaren möjlighet att städa upp och rensa sin kod, vilket minskar risken för onödig komplexitet i koden och gör den mer lättförståelig. Andra utvecklare kan enkelt sätta sig in i koden och vidareutveckla den, vilket medför värdefull transparens. Omfaktorering gör med andra ord koden enklare och tydligare att läsa, både för den som har utvecklat koden och för dem runtomkring.
.
Kandidatuppsats i Informatik 15 Hp Pawel Goralczyk 820915 Anders Nyström 830520 Handledare: Roland Nilsson
1. INLEDNING 4
1.1BAKGRUND 4
1.2PROBLEMPERSPEKTIV 5
1.2.1FRÅGESTÄLLNING 5
1.2.2SYFTE 5
1.3AVGRÄNSNINGAR 5
1.4DISPOSITION 5
2 TEORI 6
2.1TEST DRIVEN DEVELOPMENT 6
2.1.1ENHETSTESTING 7
2.1.2MOCKOBJEKT 8
2.1.3FLEXIBILITET 9
2.1.4DOKUMENTATION 9
2.1.5LÖNSAMHET 10
2.1.6BUGGHANTERING 10
2.1.7BRA DESIGN 10
2.2TDD OCH RELATIONSDATABASER 11
2.2.1REGRESSIONSTESTING 11
2.2.2OMFAKTORERING 12
2.2.3KONTINUERLIG DATABASINTEGRATION 12
3. METOD 14
3.1UNDERSÖKNINGSMETOD 14
3.2LITTERATURINSAMLING 14
3.3URVAL AV ENHETER 14
3.4INTERVJUER 15
3.4.1URVAL AV RESPONDENTER 15
3.4.2INTERVJUGUIDE 16
3.4.3ANALYS AV INTERVJUER 17
3.6.TROVÄRDIGHET 17
4. RESULTAT 19
4.1INLEDNING 19
4.2PRESENTATION AV FÖRETAG 19
4.3PRESENTATION AV INTERVJUPERSONERNA 19
4.4MOCKOBJEKT 20
4.5ENHETSTESTNING 20
4.6OMFAKTORERING 21
4.7KODDESIGN 22
4.8FLEXIBILITET 22
4.9BUGGHANTERING 23
4.10DOKUMENTATION 23
4.11TDD OCH DATABASER 24
4.12LÖNSAMHET 25
5. ANALYS 27
6. DISKUSSION OCH SLUTSATSER 29
6.1DISKUSSION 29
6.2REFLEKTION KRING METODEN 30
6.3SLUTSATS 31
6.4FORTSATT FORSKNING 31
7. REFERENSER 32
Bildförteckning
FIGUR 1: TDD GRUNDMODELL (EGEN RITNING) 7
FIGUR 2: DATABASSCHEMA SOM EXEMPLIFIERAR OMFAKTORERING AV DATABAS (EGEN
RITNING) 12
Bilagor
BILAGA 1: PRESENTATION OM OSS OCH STUDIEN BILAGA 2: INTERVJUGUIDE
1. INLEDNING
Inledningen är en kort beskrivning av området som har valts. Vidare förklaras även problemområdet med hjälp av frågeställning och syfte. Ytterliggare förtydligande finns i form av avgränsningar och disposition.
1.1 Bakgrund
Som självständiga utvecklare har vi som skrivit uppsatsen ofta utvecklat applikationer som fungerar relativt bra med de krav som fanns i början av utvecklingsfasen. Problemen uppkommer efter ett tag då vi har lagt till nya eller tagit bort gamla funktioner, det vill säga när kravbilden förändras eller vi har behövt ändra på redan implementerade koncept. Vi har ofta byggt applikationer baserat på dagens situation utan att ta större hänsyn till framtida förändringar eller vidareutveckling av dem och vi har inte tagit hjälp av några direkta ramverk eller tekniker. Vårt sätt att utveckla kostar oss därmed emellanåt onödig tid i form av omskrivningar av stora kodstycken.
Det är först nu vi har fått upp ögonen för de olika metodiker och tekniker som finns som skulle kunna underlätta utvecklingsarbetet och på så sätt spara tid för oss som utvecklare. Vi har läst en hel del om agila metoder i skolan och fattade intresse för TDD, Test Driven Development.
TDD är en teknik som börjar få en allt mer ökad uppmärksamhet i IT-relaterad litteratur.
Larsson (2008) publicerade en artikel i Computer Sweden som behandlar storstädning av kod eller ”refactoring” (omfaktorering) som det egentligen heter. Larsson (2008) skriver att omfaktorering ska resultera i att koden får bättre struktur så att den enklare förstås av så många utvecklare som möjligt.
Larsson (2008) skriver om ett begrepp som kallas för teknisk skuld, vilket är ett vanligt fenomen bland dagens utvecklare. Det innebär att återkommande kodförändringar resulterar i svårläsbar kod som kan vara besvärlig att förstå. Omfaktorering är en lösning på problemet eftersom omfaktorering leder till att kod omstruktureras och blir lättare att förstå och hantera.
Larsson (2008) jämför omfaktorering med att arbeta i kök, där städning behöver ske kontinuerligt för att hålla rent och fräscht. De flesta utvecklare använder sig inte av omfaktorering av sin kod och det resulterar oftast i stigande underhållskostnader av systemet i och med större mängder kodrader och ökad svårläslighet. Genom att använda sig av en teknik som TDD blir omfaktorering en naturlig del i systemutvecklingen. Detta är bara ett exempel på problematik inom systemutveckling som kan lösas med TDD.
Jeffries och Melnik (2007) tar upp TDD som en vidare utveckling av Extreme Programming (XP) och går ut på att testbar kod av hög kvalité skapas redan i början av utvecklingsprocessen. Att först skriva kod och sedan testa den, som utvecklare gör i traditionella metodiker och tekniker, medför oftast att processen i slutändan tar onödigt lång tid eftersom mycket tid behöver läggas på exempelvis felhantering och omfaktoreringar under eller efter testprocessen. TDD-tekniken är en disciplin av design och programmering där varje nytt kodstycke är skrivet på ett sådant sätt att det ska kunna testas enskilt som en naturlig del i utvecklingsprocessen.
TDD-tekniken går till så att för varje utökning av programmet skrivs först ett test med alla specifikationer och krav på vad programmet ska utföra. Först därefter skrivs kodstycket in i programmet som ska utföra de önskade uppgifterna. Kodstycket skrivs på ett sätt så att det
bara ska klara av att genomföra testet, medan vidare finslipning görs vid en senare fas. När den nya funktionen är implementerad utförs även de gamla testerna igen så att utvecklarna kontinuerligt ser att applikationen fungerar i sin helhet efter varje adderad funktionalitet.
1.2 Problemperspektiv
De flesta större företag har någon form av utvecklingsprojekt med både programmering och databaser inblandade. Det är sällan applikationer utvecklas helt nya från grunden, utan fungerande underhåll av redan existerande kod och kontrollerade förändringar av den funktionalitet som redan är implementerad blir nödvändigt i allt större grad. Ofta blir koden snabbt komplex och rörig när funktionalitet läggs till eller förändras och det är vanligt att utvecklare inte vill in och röra i oöverskådliga kodstycken, utan istället lägger till än mer kod för att införa förändringarna. Den senare tidens utvecklingsmetodiker och tekniker har därför fokuserat på hur utvecklare kan hålla koden transparent och fri från onödig komplexitet. En av de tekniker som beskriver hur man kan göra detta är TDD, Test Driven Development. Vi är intresserade av att undersöka de möjligheter som TDD tillför vid utveckling av nya applikationer vid objektorienterad programmering.
1.2.1 Frågeställning
Hur kan TDD stödja en mer effektiv utvecklingsprocess vid objektorienterad utveckling av applikationer?
1.2.2 Syfte
Syftet är att belysa de fördelar som finns med att använda TDD vid utveckling av nya applikationer. Vi vill undersöka TDD`s sätt att kontinuerligt testa kod som en naturlig del i utvecklingsprocessen i jämförelse med traditionella tillvägagångssätt där utveckling och testning i stor utsträckning sker separat. Meningen är att vi ske ge utvecklare som är involverade i programmeringsfasen en mängd argument till varför TDD kan vara lämplig teknik vid utveckling av applikationer.
1.3 Avgränsningar
Vi har avgränsat oss till att diskutera principer och tillvägagångssätt inom TDD-tekniken och kommer inte att gå in på vad detta innebär för själva strukturen eller designen av programkoden.
1.4 Disposition
Uppsatsen är uppdelat enligt följande delar. Del 1 är en inledning i vilken vi diskuterar uppsatsen syfte, redogör för frågeställningar och ger en kort förklarande bild av ämnet. I del 2 redogör vi för teorin som är insamlat för ämnet. Del 3 sammanfattar de olika metoder som vi har använt oss av under undersökningens gång. I del 4 redogör vi för själva undersökningen och sammanfattar resultatet. Del 5 är en analys av resultatet och en jämförelse mot teorin.
Slutligen i del 6 följer en redogörelse av vad vi har kommit fram till.
2 TEORI
Teorin innehåller det undersökningsområde vi har valt att inrikta oss på i studien. Teorin kommer att ge en förklarande bild av TDD som teknik vid utveckling av applikationer och TDD som teknik vid utveckling av databaser. Slutligen kommer TDD´s effektivitet och lönsamhet att tas upp.
2.1 Test Driven Development
Martin (2007) skriver om TDD som en disciplin som hjälper utvecklarna att få fram ren och flexibel kod som ska fungera korrekt. Det ska även vara möjligt att utveckla koden inom den tidsram som finns. Grundstommen i tekniken är att utvecklaren inte får ändra eller införa programkod utan att ett testfall först är skrivet. Både Martin (2007) samt Jeffries och Melnik (2007) skriver om en trestegs fas inom TDD. I den första fasen som kallas röd befinner utvecklaren sig i så länge som testet inte fungerar. Så i denna fas skrivs ett test med specifikationer och krav om vad programmet ska klara av att utföra. Funktionen som skrivs för applikationen kommer inte komma igenom testet i och med att funktionen inte är implementerad än. Sedan skrivs kod så utvecklaren kan komma igenom testet. Testet behöver inte fungera korrekt utan det räcker att kod har börjat skrivas. Koden kan alltså i denna fas innehålla en mängd buggar. När utvecklaren kommer igenom testet kommer den andra fasen som kallas grön. I denna fas så ska kodstycket skrivas så att det går igenom testet. Kodstycket som skrivs ska vara enkelt och inte för komplicerat, den ska bara klara av sin uppgift. I den sista delen som är omfaktorering ska koddesignen förbättras och utvecklaren ska utföra/pröva de tidigare testerna igen. Efter tredje steget går utvecklaren tillbaka och skriver ännu ett test med specifikationer och krav på vad programmet ytterliggare ska klara av och så följs livscykeln kontinuerligt tills programmet är tillfredställande och det inte finns fler funktioner som programmet ska uppfylla. Programmet byggs på genom att det hela tiden skrivs nya tester och kodstycken tills programmet har en helhet (se figur 1).
Dessa tre steg sammanfattas följande:
• Röd: Ger utvecklaren feedback angående testen.
• Grön: Ger utvecklaren feedback angående koden.
• Omfaktorering: Nu ska designen/strukturen av koden förbättras.
Dessa tre regler gör att utvecklaren kommer in i en loop. Martin (2007) förklarar att det ibland kan kännas meningslöst att följa dessa riktlinjer till punkt och pricka. Ibland kan ett längre test vara nödvändigt, ibland kan det behövas skriva mer produktionskod och ibland skrivs tester efter att produktionskoden redan är skriven. Om testresultatet är grönt, det vill säga att testet har exekverats och fått godkänt, då får utvecklaren tillåtelse att lägga in kodförändringen.
Newkirk och Vorontsov (2004) skriver att TDD ska uppfylla minst två krav.
• Det första kravet är att kod aldrig får skrivas innan det finns specifikationer och krav på vad testet ska genomföra.
• Det andra kravet är att duplicering av kod ska vara möjlig att eliminera från testet.
Duplikation är resultat av dåligt skriven kod. Det resulterar i dålig orientering i koden då utvecklarna oftast med tiden glömmer var dupliceringen finns. Om det finns en duplicering i koden är utvecklaren ansvarig för att eliminera den. En regel som även
finns inom Extreme Programmering (XP) är ”Once and Only Once!”, något som kan kopplas till duplicering av kod.
En annan viktig aspekt inom TDD är enkelheten. Newkirk och Vorontsov (2004) belyser att enkelheten är mycket mer komplicerat än det verkar. Koden måste skrivas så att den förstås av alla utvecklare och så att den passerar testfallet, eftersom det är testfallet som beskriver hur applikationen är tänkt att fungera. Svårigheten ligger i att skriva koden så enkelt att den
”bara” passerar testfallet. De flesta utvecklare vill göra koden så bra som möjligt, vilket kan resultera i att de utvecklar funktionalitet som inte funnits med i kraven för att säkra inför framtida förändringar som kan tänkas uppstå. Detta resulterar i att förutom underhåll av nödvändig funktionalitet måste underhållet även inkludera de funktioner som blivit implementerade av utvecklarna med tanke på framtiden.
Karamat och Jamil (2006) visar hur TDD fungerar, vilket illustreras på figur 1. Först skapas en interaktion med kunden för att sammanställa kraven. Sedan lägger utvecklaren till ett enhetstest med krav för vad finktionaliteten ska klara av att göra. Utvecklaren kompilerar sedan enhetstestet, vilket kommer resultera i att enhetstestet inte går igenom eftersom koden för enhetstestet inte är skapad än. Vidare skrivs kod så att kompileringen av enhetstestet lyckas. Om enhetstestet inte går igenom kompileringen så ändrar utvecklaren sin kod tills kompileringen av enhetstestet lyckas. Slutligen omfaktoreras koden och ny interaktion med kunden tas för att komma överens om ännu ett krav på vad applikationen nu ska utföra.
Figur 1: TDD grundmodell (egen ritning)
2.1.1 Enhetstesting
Enligt Kim, Park och Wu, (2006) är enhetstester tester som testar enbart en enhet och endast den enheten. Om det uppstår ett fel som inträffar utanför denna enhet kommer enhetstestet
inte att upptäcka detta fel. En viktig princip för enhetstester är att varje enhetstest ska testa en individuell del av en klass istället för att testa helheten för klassen. Detta är något som blir mer uppenbart ju komplexare en klass är. En annan princip är att enhetstester inte bara ska verifiera funktionaliteten av en klass utan också interaktionen med dess närliggande klasser eftersom testfallen snabbt ökar i komplexitet. Enhetstesterna för den önskade funktionaliteten skrivs innan själva produktionskoden är skriven. Syftet med detta är att ha möjlighet till att göra snabba och säkra förändringar i koden. Meningen med enhetstestning är att skapa små och specifika testfall för att kunna förenkla felsökningen när ett fel uppstår.
Enhetstestning utförs generellt sätt enligt följande:
1. Fastställd förberedelse
I förberedelsefasen är resurserna fastställda, vilket är nödvändigt för att kunna starta ett test. Ett exempel på detta skulle kunna vara om du behöver verifiera att ett ärende har rätt e-post och text. Så måste kodstycket som skickar informationen vara skapad.
2. Implementering av testkoden.
Här implementeras själva testkoden, för att kunna kontrollera funktionaliteten av en funktion i ett enhetstest. Även en förväntad, fördefinierad output ska presenteras i denna fas som till exempel att rätt e-post verifieras.
3. Testkörning
Här testar utvecklaren testkoden.
4. Verifiering
När själva testet är genomfört, så genomförs en verifikation på att allt gått rätt till under testet.
2.1.2 Mockobjekt
Mockobjekt är något som utvecklarna kan använda sig av vid utveckling och testning av nya applikationer. Enligt Kim, Park och Wu (2006) så kan mockobjekt användas för att verifiera interaktionen av en klass under ett enhetstest. Mockobjektet förmedlar ett svar till metoden som anropas genom att ersätta det verkliga objektet med ett mockobjekt, det vill säga ett konstgjort objekt som håller den information det verkliga objektet förväntas ha om det fungerar korrekt. Ett mockobjekt används oftast när utvecklaren vill ersätta något tidsödande objekt som kommunicerar med ett externt system som databas, server och så vidare.
Mockobjekt gör på så sätt enhetstestningen enklare och snabbare. Enligt Freeman och Pryce (2007) spelar det stor roll vad objektet gör vid objektorienterad programmering, hur varje objekt svarar och påverkar sin omgivning. Mockobjekt hjälper utvecklaren att skriva flexibel, välstrukturerad kod, bestående av objekt som är enkla att binda samman då de känner till minimalt om situationen eller systemstrukturen.
Konceptet med mockobjekt är enkelt och går ut på att klassen isoleras genom att byta ut dess beroenden med mockups. I varje enhetstest beskrivs interaktionen som förväntas av objektet med dess grannobjekt och simulerar all respons som kommer från testet. Under testet kontrolleras mockobjekten så att utfallet av anropet blir som förväntat. Kim, Park och Wu, (2006) och Freeman och Pryce (2007) skriver även om stubs som används för att imitera objekt som är dyra att skapa eller att manipulera. Det är så kallade dummy-implementationer av produktionskod som ger tillbaka fullständiga resultat. Mockobjekt agerar som stubs, men innehåller också försvarsmetoder för att verifiera interaktionen av en klass under ett
enhetstest. Freeman och Pryce (2007) påpekar att ett objekt som testas inte kan göra annat än att sända meddelande och ta emot svar.
Kim, Park och Wu (2006) talar om att fördelen med att använda mockobjekt är att de hjälper till att få enhetstestet att exekvera hastigt och smidigt. Dessutom blir enhetstestet mer intuitivt så att utvecklarna kan identifiera de förväntade interaktionerna genom att rensa undan mockobjekten genom tvång. Mockobjekt används vanligtvis i följande scenarion:
• När ett test tar för lång tid att köras.
• När ett test inte körs kontinuerligt.
• När utvecklarna inte har möjlighet att utföra tester alls.
• När samarbetet kan generera i händelser som utvecklarna inte enkelt kan återskapa med hjälp av ett enhetstest.
• När ett system innehåller ett stort beroendeförhållande.
Det finns enligt Freeman och Pryce (2007) ett antal problem med mockobjekt:
• För tidig sammansättning av objekt. Utvecklare förlitar sig för mycket på att mockobjektets objektsammansättning samarbetar.
• Mockobjektets kod kan vara svårläst.
• Mockobjekt har en tendens att göra koden ömtålig. Koden ska förstås av så många som möjligt, inte bara av utvecklaren som har skrivit den.
2.1.3 Flexibilitet
Martin (2007) skriver om utvecklarna som inte städar upp (rensa koden från onödiga funktioner) i sin kod. Han menar på att många är helt enkelt rädda för att applikationen eller en viss funktion i applikationen slutar fungera då de städar i koden. Många resonerar som att
”ändra inte det som redan fungerar”. Det gör att det ligger närmre till hands att lägga till ytterligare kodstycken än att ändra i dem som redan finns. TDD hjälper till att eliminera den här rädslan då utvecklaren nästan direkt kan få överblick över hur ändringarna påverkade funktionaliteten. Klarar programmet av alla tester så är det inte troligt att ändringen har gjort någonting oförutsägbart. Testerna gör små ändringar virtuellt riskfria. Martin (2007) stödjer sina påståenden med ett projekt som han har jobbat med som heter FitNesse (www.fitnesse.org) och som består av 45000 rader kod samt nära 600 filer. Han menar på att även stora ändringar inte innebär någon större risk att förstöra koden. TDD hjälper utvecklarna att städa upp rörig kod utan att de riskerar att något händer. Användandet av TDD låter oss göra ändringar på delar av koden utan att riskera sidoeffekter i andra delar av koden.
Martin (2007) lyfter fram ändringar som de gjort i deras projekt genom att bryta ner större tester i en sekvens av mindre tester och på så sätt gjort stora ändringar av systemet utan några större problem.
2.1.4 Dokumentation
Martin(2007) skriver om dokumentationen som ett annat område som drar stora fördelar av TDD. Enhetstestning som orsakas av TDD får oss att skriva en hel del text. Testen blir en så kallad ”kokbok” i vilken vi lär oss att programmera genom att titta på och ta efter färdiga kodstycken. Martin (2007) skriver om varje enhetstest som en isolerad bit av kod som förklarar hur en del av systemet fungerar. Om någon vill veta hur ett speciellt objekt skapas så finns det ett enhetstest för att skapa just detta objekt. Utvecklaren beskriver varje del av
systemet med ett enhetstest. Enhetstesterna är ovärderliga dokument som är skrivna i ett språk som ska förstås av samtliga utvecklarna. De är så kallade ”low-level design documents” som beskriver systemets struktur och interaktionen så utförligt att även om produktionskoden skulle gå förlorad så skulle utvecklaren kunna återskapa hela systemet med hjälp av testerna.
Även dessa påståenden styrker Martin (2007) med erfarenheten av sitt FitNesse projekt. Dock påpekar han att några enhetstester härstammar av andra basobjekt som i sin tur härstammar från andra basobjekt, vilket kan göra det hela lite svårare att läsa och följa.
2.1.5 Lönsamhet
Karamat och Jamil (2006) tar upp frågan om dagens mjukvaruföretag som tävlar mot varandra om kunder, som i sin tur väljer applikationer beroende på vilken standard de håller. Slutsatsen som framkommer i artikeln är att den bästa applikationen är den som har testats tillräckligt många gånger.
Applikationer som testas i slutet av utvecklingsprocessen innebär oftast stora kostnader, vilket ökar den slutliga kostnaden för applikationen. En lösning på att minska kostnaderna enligt Karamat och Jamil (2006) är just TDD då det skapas tester i början av processen innan kodningen har kommit igång. TDD går ut på att det hela tiden skrivs tester så att stora tester bryts ner till mindre hanterbara tester. Den här tekniken innebär att kompileringen tar mindre tid och att det blir mycket enklare att hitta buggar i koden som behöver genomsökas. Karamat och Jamil (2006) har tagit fram formler och grafer för lönsamheten med att använda TDD vid utveckling dessa formler och grafer finns presenterade i deras artikel.
2.1.6 Bugghantering
Enligt Martin (2007) hittas nästan alla buggar direkt (inom en minut) som har kommit in i systemet med hjälp av TDD. En debugger (ett program som hjälper dig hitta buggarna) behövs oftast inte användas för att hjälpa till att hitta buggarna i systemet. Egentligen behöver utvecklaren inte göra alls mycket eftersom de vet var buggarna är då de precis lades till. Dock är det inte riktigt så enkelt eftersom olika enhetstester inte tar lika lång tid att köra. Även detta stödjer Martin (2007) med hjälp av sitt FitNesse projekt. Han påstår att de i sitt FitNesse projekt begränsar enhetstesterna som körs mot den klassen som håller på att modifieras. Detta minskar test tiden till 1-2 sekunder, vilket innebär att detta enbart körs cirka en gång i halvtimmen. Det kan dröja upp till 30 minuter innan en bugg upptäcks i systemet. Han menar också att han på grund av detta inte har behövt använda sig av en debugger speciellt ofta, även om det i vissa fall kan vara nödvändigt som till exempel vid misslyckanden av enhetstestningar.
2.1.7 Bra design
Bra design inom TDD är vad Martin (2007) förknippar med testbar kod. Det går inte att testa en klass med en funktion som kallar på en annan funktion i en annan klass som har okända effekter. Funktionen som anropas behöver omkopplas och på så sätt testas utan att påverkan från den andra funktionen sker. Detta är inte så krångligt som det låter då det enbart är välplanerad objektorienterad design (OOD). OOD tillåter dig att koppla om funktioner från varandra medan TDD upprätthåller denna omkoppling. Detta resulterar i en sorts applikationsstruktur, vilket även bidrar till att applikationen får en bra design. Bra design är inte gratis och TDD garanterar inte en bra design. Däremot så hjälper TDD utvecklarna att skapa en bra design eftersom de får strukturen för applikationen redan från början. Hade de inte använt sig av TDD så kanske de inte hade tänkt på denna faktor och koden skulle därmed inte få lika bra design utan TDD. (Martin, 2007)
2.2 TDD och relationsdatabaser
En annan viktig aspekt inom TDD är att den är applicerbar till relationsdatabaser. Ambler (2007) skriver om TDDD (Test Driven Database Design) som är en teknik som inte skiljer sig särskilt mycket från TDD. Inom relationsdatabaser är det samma procedur där vi specificerar databasbeteendet med hjälp av databastester. TDDD är inte en egen teknik i sig utan TDDD beskriver hur TDD appliceras på databasutveckling.
Ambler (2007) uppmanar utvecklare att utveckla sina databaser i samma takt som de utvecklar koden. Detta gäller enbart om databasen redan existerar. Ibland skrivs ett enhetstest som inriktar sig på applikationens uppförande och ibland är det databasens uppförande som påverkas. TDDD är viktig att tillämpa inom applikationer som använder sig av databaskopplingar. För det första så drar alla TDD-utvecklade applikationer nytta av TDDD då små och säkra steg hela tiden tas samtidigt som omfaktorering låter utvecklaren hålla koden på hög standard genom hela livscykeln. TDDD ger också utvecklaren körbara systemspecifikationer, vilket medför att utvecklaren håller sig motiverad att hålla helheten uppdaterad genom hela processen.
För att TDD ska kunna tillämpas för relationsdatabaser behövs regressionstestning, omfaktorering och kontinuerlig integration.
2.2.1 Regressionstesting
Inom regressionstesting skriver Ambler (2007) om validering av databaserna genom att köra heltäckande tester av databasmiljön så fort utvecklaren gör en ändring av databasen eller kommunicerar med den på ett nytt sätt. När Ambler (2007) talar om testning så talar han om två olika tester, yttre testet och inre testet.
Yttre testet
Utvecklaren bör göra ett yttre test för att se hur systemet kommer att integrera med databasen.
Testerna ur databasens synvinkel är tester som kallas för ”black-box” tester. Dessa tester innebär tillexempel hårdkodade SQL-frågor som skickas till databasen. Detta innebär att utvecklaren försäkrar sig om att SQL-frågan eller en vy returnerar det förväntade resultatet.
SQL-frågan som innebär en beräkning ska returnera ett korrekt värde. En speciell användare med ett speciell ID ska enbart kunna ta del av den information som finns tillhands för just denna specifika användare och alltså varken få tillgång till mer, mindre eller annan information. Ambler (2007) belyser att de yttre testerna är lätta och göra då det finns många verktyg för just detta. Han uppmanar även att använda sig av samma verktyg som utvecklaren använder för att testa sin applikationskod.
Inre testning
De inre databastesterna innebär uppförandet av databasimplementeringar samt datavaliditeten.
Ambler (2007) förklarar att det inte är några större konstigheter att skriva tester för lagrade procedurer om utvecklaren kan skriva tester för sin applikationskod. Till skillnad från de yttre testerna så kallas testerna för inre testning för ”clear box” tester. I testerna ingår kontroll av de lagrade procedurerna, validitetskontroller av parametrar som skickas in och validitetskontroller för resultatet som de returnerar. Ett exempel skulle kunna vara att ett varningsmeddelande returneras när det skett en felskrivning till en tabell. För att komma åt verktyg som är till hjälp vid testning så är det svårare när det handlar om de inre testerna. Men det finns välutvecklade verktyg både för Microsoft SQL server och för Oracle.
2.2.2 Omfaktorering
Vi har tidigare nämnt en artikel som betonade vikten av omfaktorering av applikationskod.
Ambler (2007) beskriver omfaktorering som en process i små steg i vilken utvecklaren gör små ändringar i koden som förbättrar koddesignen utan att förändringar av semantiken görs.
Genom omfaktorering blir koden bättre över tiden. Detsamma gäller även omfaktorering av databaser. Databaser inkluderar strukturella aspekter som tabeller och vyer, funktionella aspekter som triggers och lagrade procedurer och informativa aspekter som är själva informationen i databasen. Ambler (2007) skriver om många sätt att omfaktorera databasen.
Ett av sätten är att ta bort vyer som inte längre används eller att flytta en kolumn till en tabell i vilken den passar bättre. Det finns vissa svårigheter med omfaktorering av databaser och ett av dessa är att ändra till exempel hur värdena i kolumnerna lagras. Ett exempel på detta skulle kunna vara telefonnumret 042131313. Om det ändras till 042-131313 måste även applikationskoden ses över så att den fortfarande fungerar som den borde.
Figur 2: Databasschema som exemplifierar omfaktorering av databas (egen ritning)
(a) originalschema över databasen i vilken ”Saldot” kolumnen är på fel sida.
(b) Under omfaktoreringsprocessen måste databasen både klara av den gamla och den nya strukturen.
(c) Eftersom utvecklarna har uppdaterat alla sina applikationer som använde sig av det gamla databasschemat så kan det gamla schemat tas bort permanent.
2.2.3 Kontinuerlig databasintegration
Ambler (2007) skriver om kontinuerlig databasintegration som är en process i vilken gruppmedlemmar kontinuerligt integrerar ändringar till deras databasinstanser, vilka inkluderar strukturella, funktionella samt informativa ändringar. Så fort någon rapporterar en ändring i databasen bör alla som jobbar med databasen ladda ner ändringen och applicera den till deras egen databasinstans. Ambler (2007) beskriver olika ”best practices” för kontinuerlig databasintegration:
• Automatisera uppdateringarna.
Databasen borde själv upptäcka om den behöver uppdateras. Detta är ett nytt koncept inom databaser men det håller på att utvecklas inom Ruby och dbdeploy.
• Allt bör vara versionshanterat.
Det mesta inom projektet bör versionshanteras såsom script, datamodeller, produkter mm. En enkel regel säger att så länge något är värt att producera bör det versionshanteras.
• Utvecklare bör ha en egen databaskopia.
Enligt Ambler (2007) bör utvecklarna först jobba i sina egna sandlådemiljöer (testmiljöer) innan de ger sig in på produktionsmiljön. De bör testa allt i en säker miljö först. Detta medför en stor riskminskning.
• Automatisering av databasskapande.
Det ska vara enkelt att återskapa en databas om till exempel en ny utvecklare kommer in i gruppen eller om en databas behöver kopieras till en annan plats. Att återskapa en databas är något som utvecklare gör ofta och därför bör det vara enkelt att göra detta.
3. METOD
Metodkapitlet går genom tillvägagångssättet och genomförandet av studien.
3.1 Undersökningsmetod
Målet med vår undersökning är att ta reda på vilka fördelar som finns för utvecklare om de använder sig av TDD som teknik vid utveckling av nya applikationer. För att ta reda på detta har vi valt att göra en kvalitativ undersökning. Holme och Solvangs (1997) skriver om de olika styrkorna som finns med en kvalitativansats. En av styrkorna enligt Holme och Solvang (1997) är att skapa en så vardaglig undersökningssituation som möjligt. Vi har därför valt att göra personliga intervjuer eftersom vi anser oss komma närmare våra respondenter. Att välja en kvalitativ ansats har visat sig vara resurskrävande, men vi har förmodligen fått ut mer av intervjuerna eftersom vi har haft möjligheten att ställa följdfrågor vid behov. Att ställa följdfrågor skulle inte vara möjligt om vi skickade ut ett frågeformulär med statiska svarsalternativ.
3.2 Litteraturinsamling
Litteraturen vi har använt oss av innehåller information om TDD som teknik, databaskopplingar och programmering. Artiklarna har vi hämtat från IEEE och ACM då dessa källor innehöll information mest lämpad för vår undersökning. Vi har använt sökord som ”test driven development”, TDD”, ”databases”, ”programming”, ”benefits” och olika kombinationer av dessa ord för att på så sätt få fram så detaljerade sökningar som möjligt. När vi har hittat lämpliga artiklar som behandlar TDD har vi även letat efter annat lämpligt material med hjälp av referenserna som finns i artiklarna. Vi har även efterforskat på författarna och deras meriter för att på så sätt öka trovärdigheten i vår uppsats.
3.3 Urval av enheter
Vi har valt ut två mjukvaruföretag som vi har genomfört vår studie hos. För att få fram företagen gjorde vi en sökning på Internet (Google) efter mjukvaruföretag stationerade i västra Sverige. När vi hittade lämpliga företag skickade vi ut en presentation om oss och om den studie vi ville göra till de företag som vi hade hittat (Bilaga 1). Företagens storlek och inriktningsområden varierar. Detta för att vi ska få en så stor variationsbredd som möjligt i materialet. Variationsbredden i vetenskapliga undersökningar är något som Holme och Solvang (1997) belyser starkt i sin bok. Vi vill i vår undersökning försöka att få fram ett så stort informationsinnehåll som möjligt, vilket vi får genom att använda en bredare variationsbredd. Vi har därför valt att ha med ett mindre (med mindre menar vi ca 10 anställda) och ett större mjukvaruföretag (med större menar vi över 1000 anställda) för att på så sätt kunna få fram ett bredare underlag. Vi har avgränsat oss till enbart två företag eftersom vi anser att vi får en tillräcklig variationsbredd då.
Genom att följa Holmes och Solvangs (1997) riktlinjer så har vi använt frågeställningen för att klargöra vilka enheter och vilka egenskaper hos enheterna vi önskar få upplysningar om.
Då vi inte är ute efter ett generellt resultat så lämpar sig en kvalitativ undersökning bäst för vår studie. Vi har använt oss av två företag inom vilka arbetssättet varierar. Vi har valt att intervjua endast sex personer som arbetar med TDD som teknik, vilket innebär att resultatet inte blir generellt.
3.4 Intervjuer
I en kvalitativ undersökning ingår att använda sig av personliga djupintervjuer vilket vi har gjort. Vi anser att vi genom personliga djupintervjuer lär känna respondenterna och får en mer naturlig uppfattning om deras erfarenheter och tankar, vilket stöds av Kvale (2007). Vi tror starkt på Kvales (2007) argument som förespråkar djupintervjuer och säger att vi får en helt annan uppfattning av människor när vi träffar dem och samtalar med dem i verkligheten än om vi tillexempel skulle utföra en enkätundersökning. Därför tror vi att resultatet i vår undersökning kommer att bli bättre om vi använder oss av personliga djupintervjuer.
En stor fördel med att använda djupintervjuer är dess flexibilitet. Vi kan följa upp idéer, sondera svar och gå in på motiv och känslor på ett sätt som är omöjligt i en enkät. En respons ges i tonfall, mimik och pauser och ger oss information som ett skriftligt svar aldrig skulle avslöja. Påståendet stöds väl av Bell (1993) Vi har valt att använda oss av enbart intervjuer i studien eftersom vi kommer närmare inpå den intervjuade.
Vår undersökning bygger på frågor, resonemang och funderingar vi undrar över och vill få säkrare svar på. För att få ett sådant svar börjar vi formulera olika tankeställningar dvs.
diverse antaganden. Enligt Jacobsen (2002) så kommer tankeställningarna från det som vi kan kalla tankevärld. Vi antar att vissa tillfällen ser ut på ett visst sätt, men vi kan inte riktigt förstå varför de ser ut på detta sätt. När vi utför vår undersökning vill vi ha möjlighet att kunna få reda på hur det verkligen ser ut på företagen och hur TDD används. Allt detta sker med hjälp av djupintervjuer. Detta vill vi göra så optimalt som möjligt och följer därför Trost (1997) genom att använda oss av enkla och raka frågor till respondenterna i våra djupintervjuer. Förhoppningen är att vi ska få fram detaljrika svar så att det finns tillräckligt med material i de intervjuer vi har att analysera. Det är viktigt att frågorna som används under djupintervjuerna är genomtänkta och välformulerade för att ge vår undersökning ett bra underlag.
3.4.1 Urval av respondenter
Hartman (1998) beskriver en metod som vi har valt att använda på ett av företagen vid urvalet av våra respondenter. Metoden heter snöbollsurvalet. Metoden innebär att först intervjua en person och sedan frågas personen om vem mer som skulle kunna vara en lämplig kandidat för undersökningen. Sedan intervjuas den rekommenderade personen som i sin tur får ge förslag på fler kandidater. Snöbollsurvalet är riskabelt eftersom risken finns att de intervjuade personer är rätt lika varandra och på så sätt förloras kontrollen över vem det är vi intervjuar.
Däremot anser vi att detta inte är en stor risk. Vi tror att vår målgrupp som sådan är relativt likriktad, men vår uppfattning är att även om personerna i sig är lika och använder samma teknik så kan de ha olika uppfattningar om tekniken i sig. På ett av företagen gick inte snöbollsurvalet att använda eftersom företaget enbart bestod av två personer där båda använde sig av TDD. Därför intervjuades båda.
Vi valde även att använda oss av ett subjektivt urval, vilket innebar att vi handplockade urvalet till undersökningen för att få tag på de personer som satt inne på värdefull information för vår uppsats (Denscombe, 2000). Vi försökte komma i kontakt med personer som har erfarenhet av TDD, men inte alltid haft TDD som teknik, för att få en mer rättvis bild av tekniken. Personer hittar vi på de företag som vi valt ut att ha med i studien. Vi skickade ut förfrågningar till företag som ansågs lämpliga för undersökningen (Bilaga 1) Holme och Solvang (1997) skriver om vikten av att rätt respondenter är med i urvalet. Fel personer i urvalet kan leda till att hela undersökningen blir värdelös i relation till utgångspunkten, påståendet styrks även av Hartman (1998) som säger att några felaktiga val kan leda till att
studien resulterar i att bli skev och inte ge oss den kunskap vi är ute efter. Nu när vi ska undersöka människor som har erfarenhet av TDD kan vi inte undersöka människor som aldrig har arbetat med det eller människor som inte vill arbeta med TDD. Urvalet kan inte göras slumpmässigt eller tillfälligt utan måste ske systematiskt utifrån vissa medvetet formulerade kriterier skriver Holme och Solvang (1997). Detta har vi gjort genom att basera vårt urval på frågeställningen. Hartman (1998) menar på att urvalet av respondenter måste vara väl genomtänkt, och hur detta görs beror på vad vi är ute efter för kunskap och vad vi har för praktiska möjligheter.
3.4.2 Intervjuguide
Trots att den kvalitativa intervjun är ganska fri, är det viktigt att vi förbereder oss ordentligt inför djupintervjun. Som hjälp har vi använt en intervjuguide, som är en förberedelse för själva intervjun.
Hade vi inte haft en intervjuguide att följa är risken att vi lämnar intervjun med material som inte har någon relevans för undersökningen. I en intervjuguide tar vi upp de teman som ska diskuteras och ger en ordning till dessa. Ordningen är väldigt viktig i och med att vi ska få den intervjuade i rätt stämning. Vi väljer en form som heter trattekniken, vilket innebär att vi inleder med att göra diskussionen allmän för att sedan gå in mer specifikt på området för att göra frågorna mer precisa.
Vi följer Hartmans (1998) riktlinjer för att dokumentera intervjun. Vi kommer att dokumentera samtalet med hjälp av en mp3-spelare som har stöd för inspelning för att lättare kunna dokumentera det som sägs. Även andra aspekter som beteende, minspel med mera ska ses över. Det är viktigt att vi gör en inspelning för att kunna verifiera att det som citeras verkligen är sagt.
Vi har valt att använda oss av följande teman under vår intervju för att på bästa sätt besvara vår frågeställning. Teman som vi använder oss av under intervjuerna är samma som vi baserat vår litteraturstudie på. Undantaget är första temat som är ett introducerande tema för att få information om respondenten. Teman är följande och vi kommer att följa dem enligt nedskriven ordning:
Erfarenhet: Introduktionstema så att vi får en insyn om kunskap hos respondenten.
Mockobjekt: Vi vill veta om respondenterna använder sig av mockobjekt och om de anses användbara.
Enhetstestning: Vi vill veta om respondenterna använder sig av enhetstestning och om de hjälper till att få koden/strukturen att bli bättre.
Omfaktorering: Vi vill veta om omfaktorering hjälper utvecklarna att få en bättre koddesign och om de använder sig av detta.
Koddesign: Här undrar vi om koddesign är viktigt för respondenten och om de ändrar sin kod efter lyckade enhetstester för att på så sätt förbättra koddesignen.
Flexibilitet: Vi är intresserade av att veta om TDD hjälper till att få koden mer flexibel, dvs.
lättare att ändra om i och omstrukturera.
Bugghantering: Vi vill veta om bugghanteringen blir bättre med hjälp av TDD.
Dokumentation: Vi undrar om respondenterna tänker på dokumentationen och om detta är något som hjälper dem vid utveckling av applikationer.
TDD och databaser: Eftersom databaser kan förekomma vid utveckling av applikationer så undrar vi om respondenterna använder sig av TDDD/TDD vid utveckling av sina databaser och om dessa omfaktoreras. Vi undrar även om de använder testmiljöer för sina databaser.
Lönsamhet: Vi vill få en inblick om respondenterna tycker att TDD är lönsamt att använda eller inte.
(En mer utförlig intervjuguide finns som Bilaga 2) 3.4.3 Analys av intervjuer
När vi analyserar intervjumaterialet så ska vi försöka att hitta det intressanta som respondenten har tagit upp. När djupintervjuerna är klara kommer vi att skriva ut intervjuerna och med hjälp av dessa utskrifter analysera svaren. Vi följer Bells (1993) anvisningar som syftar på att utskriften av materialet i princip är ett krav för att analysen ska vara möjlig att genomföra.
Genom att följa Hartmans (1998) anvisningar så kommer vi att dela upp analysen i två steg.
Det första steget är reducering av datamaterialet genom att koda det, vilket innebär att vi kommer att kategorisera, organisera och reducera vårt insamlade material. Sedan ska vi leta efter meningar i textmassan som verkar intressanta. Detta kommer att styras av vår frågeformulering och det gäller att vi hittar så många meningar som möjligt som kommer att hjälpa oss med att besvara frågeställningen. Efter att vi har funnit de meningar som vi är ute efter kommer vi att kategorisera dessa, vilket innebär att vi klassificerar dem och för samman meningar som handlar om samma sak.
Efter kategoriseringen så utförs själva tolkningen. Tolkningen kommer att resultera i att vi får fram ett resultat. De olika kategorierna kommer att sättas i relation till varandra. I vårt fall kommer vi att sätta samman de olika fördelarna i de olika områdena. I analysdelen kommer förståelsen fram som vi är ute efter i vår kvalitativa undersökning.
Intervjupersonerna kommer att få läsa igenom de citat som vi valt att använda oss av i vår analys, det kommer vi att göra för att kunna verifiera att de citat vi använt oss av har tolkats på ett korrekt och riktigt sätt.
3.6. Trovärdighet
Enligt Esaiasson, Gilljam och Oscarsson, H (2003) anses den kvalitativa metoden vara mest sårbar när det gäller trovärdighet. Vi ska informera våra respondenter om våra frågeställningar och på så sätt öka tillförlitligheten i vår undersökning. Vi anser att vi kommer att ha hög trovärdighet i vår studie av flera olika skäl. Ett av skälen är våra respondenters goda kunskaper inom ämnet och att vi kommer att ha stora möjligheter till att rätta eventuella missförstånd under intervjuns gång. En annan faktor som kommer att öka trovärdigheten ytterligare är att vi kommer att låta våra respondenter läsa genom det insamlade materialet för att sedan ha möjlighet att kommentera det.
Vi ska använda oss av en intervjuguide, vilken ökar trovärdigheten i studien ytterligare enligt Hartman (1998). Vi anser även att det faktum att vi båda kommer att vara närvarande vid intervjutillfällena och att vi kommer att använda oss av ljudupptagning och anteckningar som komplement till varandra, leder till att vi undviker att någon information går förlorad.
En nackdel med att använda sig av intervjuer är att varje intervju blir unik på grund av den specifika kontexten och de specifika intervjuobjekten, vilket i sin tur kan minska pålitligheten en aning (Denscombe, 2000).
4. RESULTAT
Här presenteras det resultat som vi har fått fram i vår undersökning. Vi har valt att dela in kapitlet i olika teman som användes i intervjuguiden.
4.1 Inledning
Vi genomförde undersökningen i ett mindre och ett större mjukvaruföretag. Vi har valt att kalla det mindre mjukvaruföretaget för företag A och det större för företag B.
4.2 Presentation av företag
Företag A levererar tjänster och applikationer som stöttar deras kunder i hälso-, miljö- och säkerhetsarbete. De vänder sig till verksamheter som i liten eller stor skala använder kemiska produkter i samband med underhåll eller tillverkning. Företag A har genom intensiv utveckling och innovativa lösningar tagit platsen som den ledande och mest expansiva leverantören av lösningar för kemikalieadministration. De erbjuder kostnadseffektiva lösningar till sina kunder som resulterar i minskad administration. Företag A förenklar vardagen för de verksamheter som hanterar kemiska produkter och förser dagligen tiotusentals personer med riskinformation med hjälp av ett verktyg där kunderna administrerar hanteringen av kemiska produkter. Personalen är erfaren och har samlat in och byggt upp en databas som idag innehåller information om tiotusentals produkter. De tjänster och system som levereras gör att kunderna, med minsta möjliga arbetsinsats, uppfyller de krav som omvärlden ställer.
Företag B är ett större mjukvaruföretag som arbetar med informationsbehandling. De har tusentals teknik- och affärspartner över hela världen, vilket gör företaget till ett globalt integrerat företag som arbetar tvärs över landsgränser för att ge kunderna tillgång till den sammanlagda kompetensen i en organisation. Företaget har kommit med flera banbrytande produkter genom åren.
4.3 Presentation av intervjupersonerna
På företag A intervjuades två personer som är aktiva i Halmstad.
• Respondent 1 är en systemarkitekt för företag A. Han har jobbat professionellt med programmering i ca 8 år och började intressera sig för TDD för cirka två år sedan.
• Respondent 2 är också en systemarkitekt för företag A. Han har jobbat med programmering i mer än 10 år, men har enbart arbetat med TDD ett antal månader.
På företag B intervjuades fyra personer som använder eller har använt sig av TDD.
.
• Respondent 3 har 20 års erfarenhet av programmering och 7 års erfarenhet av TDD.
Han har jobbat professionellt med programmering i 10 år.
• Respondent 4 har 20 års professionell erfarenhet av programmering samt 5 år av programmering med TDD som teknik.
• Respondent 5 har programmerat sedan 1999. Han började med programmering professionellt 2002. Han har uteslutande använt TDD de senaste 18 månaderna.
• Respondent 6 har programmerat och använt sig av TDD i tre år. Han har ett års erfarenhet av programmering mot databaser.
4.4 Mockobjekt
Inom TDD används mockobjekt för att hjälpa utvecklarna att skriva objektorienterad kod. Se teorikapitlet för en utförlig beskrivning av tekniken.
Resultat: Inledningsvis frågade vi våra respondenter om de använder mockobjekt. Det visade sig att det var olika från respondent till respondent om de använder mockobjekt eller inte.
Några använde mockobjekt och tyckte att det var ett bra verktyg, medan andra använde det mindre och ansåg att det var mindre bra verktyg. Respondent 4 på företag B anser att mockobjekt kan vara farligt verktyg att använda om utvecklaren inte förstår hur det ska användas. Han svarade följande:
”Använder man mockobjekt på fel sätt så blir koden sämre. I vissa sammanhang hjälper det att kunna bevisa att saker händer i en viss ordning: då är mockobjekt värdefulla.” (B4)
En annan av de respondenter som använde mockobjekt:
”I use do use mock objects. I began using mocks on my first database project in order to imitate the connection to the database for quicker running unit tests.”
(B5)
Vi frågade våra respondenter om de ansåg att mockobjekt var ett bra verktyg att använda vid utveckling. Två av våra respondenter svarade enligt följande på denna fråga.
”Although I don’t think mock objects are imperative for proper TDD, I do believe they can greatly improve the TDD experience. It is possible to replicate the same behaviour of mock objects using hand written test doubler classes for basic state testing, however, it is much more efficient to create these casses on the fly using a mock objects framework. Also, I don’t think that you can do significant interaction testing without a mock objects framework.” (B5)
“Yes. It’s quite helpful to automate some complex test cases. For example, the protocol related ones. It’s important that the mock objects can make some tests automated, which is a pleasure to run the test and provide a way to fast revise and development.” (B6)
I slutet på varje tema som vi byggde intervjuerna på ställde vi frågan om vi missat något. En av respondenterna svarade att det var flera utvecklare som använde mockobjekt för att inte behöva omfaktorera koden. Han svarade:
”Ofta ser man att mockobjekt används istället för att omfaktorera koden att ha bättre design. Det visar två misstag: först att koden blir svårare att förändra, och nästa att man inte tänker igenom andra sätt som koden kunde göra samma sak utan att behöva hjälp (från objektet som mockas).” (B4)
4.5 Enhetstestning
Enhetstester hjälper utvecklarna att beskriva själva systemet med hjälp av ett test som verifierar funktionaliteten av en funktion och den interaktion som finns med dess närliggande funktioner. Se teori kapitlet för en utförlig beskrivning av tekniken.
Resultat: Första frågan vi ställde till våra respondenter angående enhetstestning var om de använder sig av tekniken eller inte och varför de i så fall använder sig av denna. Samtliga respondenter som intervjuades använde enhetstestning. Respondent 5 på företag B ansåg att detta var något som var självklart och något som gav honom självförtroende.
”Unit testing gives me confidence in my code I wouldn’t have otherwise. As long as the tests are passing, I know that the codebase is reasonably stable.
With this confidence, I can easily add or alter functionality in the code and know that I haven’t broken previous functionality.” (B5)
Nästa fråga vi ställde till respondenterna var om de tyckte att enhetstestning var en bra teknik eller inte. Det visade sig att samtliga respondenter tyckte att enhetstestning var bra att använda och att enhetstestning hjälpte dem att få koden att bli bättre. Respondent 6 på företag B påpekade att det var enklare att finna buggarna med hjälp av enhetstestning.
” It’s automated, which means it’s handy to run. Also when a case failed, it’s very easy to locate the buggy point.” (B6)
Vi frågade respondenterna om själva koden har blivit bättre efter att de börjat använda enhetstester. En av respondenterna uttalade sig enligt följande:
”Om man använder riktig TDD (Red-Green-Refactor) så ja. Däremot är det inte lika bra att skriva testen efteråt då man redan har hängt upp sig på en design som man har hittat på. Bättre att lyssna på vad testen försöker säga och låta dem driva en till så enkel design som möjligt. Enklare design och kod är bättre.” (A1)
4.6 Omfaktorering
Omfaktorering är en process där utvecklaren i små steg gör små ändringar i koden som förbättrat designen utan att förändra semantiken. Se teori kapitlet för en utförlig beskrivning av tekniken.
Resultat: Omfaktorering är en del av TDD och det föll naturligt att samtliga respondenter att omfaktorera sin kod eller att försöka göra det så ofta som möjligt. Respondenterna ansåg att omfaktorering av kod behövdes och respondent C utryckte sig på följande sätt:
“All code needs to change, and refactoring reduces the cost of changing code.”
(B3)
Flera av respondenterna menar på att ingen kan skriva perfekt kod redan från början. De tyckte att all kod måste omfaktoreras. En annan viktig del av applikationens livscykel är att kraven för applikationer ändras hela tiden, vilket leder till att förändringar i koden blir nödvändiga. Att införa förändringar i omfaktorerad kod gör hela processen mycket lättare.
Respondent 1 på företag A tyckte att med hjälp av omfaktorering förenklas designen och redundans i koden försvinner. Respondenten 2 på företag A tyckte att omfaktorerad kod blir mycket tydligare, vilket i sin tur leder till att en annan utvecklare snabbare kan förstå koden.
Omfaktorering får även inflytande över buggarna då dessa minskar. Respondenten A2 tyckte att han fick en bättre bild av vad han egentligen gjorde efter att ha omfaktorerat sin kod.
Respondenten B5 uttryckte följande på frågan om han tyckte att koden blir bättre tack vare omfaktorering:
”Yes, I believe the code is better from evolving the design versus designing it up front since I can respond to changes and unforeseen issues as the code is written.
This frees me from having to stick to a predefined design which may no longer be relevant.” (B5)
4.7 Koddesign
Koddesign är detsamma som kodstruktur. TDD som teknik kan bidra till att koden får en bättre design och på så sätt blir lättare att utveckla. Se teorikapitlet för en utförlig beskrivning av tekniken.
Resultat: På frågan om respondenterna skriver om sin kod för att få bättre design så svarade respondenten A1 att denne inte skriver om koden utan använder sig av omfaktorering som han tidigare nämnde.
”Ett steg i taget mot så bra design som är möjlig för tillfället” (A1)
Respondenten B3 förklarade vikten av bra koddesign. Han menade på att om utvecklaren jobbar på en applikation i flera år så blir applikationen automatiskt stor och komplex. Bra koddesign hjälper utvecklaren och förstå koden flera år efter att applikationen skrivits. På frågan om applikationer med bättre koddesign är bättre än andra applikationer i vilka utvecklaren inte tänker så mycket på koddesignen, svarade respondenten B3:
” Code is design, so if the design is better, then the code is better.” (B3)
Respondent E svarade att nyckeln till en bättre koddesign är omfaktorering. Några exempel på bra koddesign är bättre namn på klasser och funktioner och borttagning av dubbletter. Han brukar aldrig skriva om koden för en bättre koddesign utan tycker att omfaktorering hjälper honom med detta.
Ett helt annorlunda svar fick vi från vår sista respondent som till och med slänger hela koden efter att ha skrivit ett test eftersom han får idéer till bättre koddesign under testningsfasen.
”With better design, we could have more clean code, which means more natural and more easy to understand and accept by others” (B3)
4.8 Flexibilitet
Flexibilitet handlar om att ändringar i koden görs på ett enkelt och smidigt sätt. Se teori kapitlet för en utförlig beskrivning av tekniken.
Resultat: Vi frågade respondenterna om de tyckte att TDD gör koden mer flexibel. Med flexibel menar vi att det är lättare att ändra om i eller omstrukturera koden. Samtliga respondenter svarade att det blir lättare att arbeta med koden då den blir enklare och mer uppdelad. Respondenten B5 svarade att samma kvalitéer som gör koden testbar automatiskt gör koden mer flexibel
”TDD encourages my code to be more loosely coupled, and loose coupling is a sign of flexibility” (B3)
”Riktig TDD driver en till att få enklare och mer ”decoupled”/uppdelad design.
Mer självständiga klasser/objekt med ett ansvar” (A1)
”The ability to insert yourself between different layers of the application, or to break the components into fully separate modules, lends itself very well to flexible code” (B5)
4.9 Bugghantering
Bugghantering handlar om hantering av fel och buggar som uppstår under applikationens utvecklingslivscykel. Se teorikapitlet för en utförlig beskrivning av tekniken.
Resultat: Följande tema behandlar ett område som är ett av de mest kostsamma inom applikationsutveckling. Vi ställde en fråga till respondenterna om vad de tycker om bugghanteringen efter att de börjat använda sig av TDD som teknik. Respondenten 1 på företag A menar att när det skapas ett test som först misslyckas så skapas en bugg, vilken i sin tur rättas till genom att skriva kod som klarar testet.
”Ordentlig kod skriven med TDD har ofta mindre antal buggar. Och koden är enklare vilket gör dem lättare att hitta.”(A1)
Både respondenterna 1 och 2 på företag A har sagt under intervjun att de inte använder en debugger lika ofta nu som förr efter att de börjat använda TDD, och menar på att det oftast är testen som påvisar vad som är felet. Behovet av en debugger blir då mindre.
Respondenterna 5 och 6 på företag B tycker inte att det har skett någon förändring i användandet av en debugger för deras del. Respondenten 5 säger att många har gått från att använda en debugger till att helt enkelt skriva fler tester, men påpekar att han själv inte tillämpat detta än. Respondenten 6 tycker att TDD bara är ett verktyg som ger dig möjlighet att hålla reda på koden på ett bättre sätt, men han tror inte att TDD hjälper att hitta buggar lättare, utan påpekar att det i slutändan fortfarande är upp till utvecklaren.
“Will we use a debugger often or not is related to the test cases, not test first or later. If we write the code first, and tests come later, we can still debugging the code without a debugger” (B5)
Respondenten B3 säger att det är lättare att hitta buggarna och belyser att TDD hjälper till att undvika duplicering av kod, vilket i sin tur leder till att det inte förekommer buggdubbletter.
Respondenten B5 tycker att det är lättare att förhindra att buggarna återkommer då ett test skrivs som ger utvecklaren full kontroll på hur buggen beter sig. Detta hjälper utvecklaren att förhindra att buggen återvänder i framtiden.
4.10 Dokumentation
Inom TDD kommer dokumentationen naturligt. Utvecklaren beskriver varje del/funktion av systemet med ett test. Dessa olika tester är ovärderlig dokumentation som är skrivet i ett språk som förstås av samtliga utvecklare. Se teorikapitlet för en utförlig beskrivning av tekniken.
Resultat: Första frågan vi ställde till respondenterna var om de ansåg att dokumentationen blivit bättre tack vare enhetstest och varför. Respondenterna hade olika åsikter om detta.
Några ansåg att det inte var speciellt många som skapade tillräckligt bra enhetstester. En av
åsikterna var att det ibland kunde vara svårt att förstå vad en viss funktion gjorde eller vad den används till. En av respondenterna svarade enligt följande:
”När dokumenteringen tar ideer från TDD-inriktade enhetstester så brukar dokumentationen ha fler exempel på hur koden ska användas. Vanligen ser man dokumentation som säger bara något som t.ex. ”metod Invoice.addBill() lägger till en Bill objekt på en Invoice”; dvs är nästan meningslös.” (B4)
En annan respondent nämnde att koden måste vara lätt att förstå och beskrev det på följande sätt:
”…but, sometimes I was thinking, if the code is clear enough, shouldn’t the code be self-explained?” (B6)
De flesta respondenterna ansåg att dokumentationen har blir bättre med hjälp av enhetstestning. Ett annat svar som framkom under intervjuerna:
”Since TDD is ”coding by intention”, or designing an API exactly as I would like to use it, the tests serve as documentation of exactly how the API is intended to be used. Also, if I have good negative test coverage, I have adequate documentation of what would happen if the API is misused. Since using TDD, when another developer has a question about the usage of a component, I can simply point them towards the appropriate test.” (B5)
Respondenterna som ansåg att dokumentation blivit bättre hade även åsikter om vad det fanns för fördelar och nackdelar med just dokumentationen. En respondent svarade:
”The biggest benefit is that the documentation constantly evolves as the tests grow. I haven’t seen any negative effects yet, however, I still do more detailed documentation for most components in a centralized wiki.” (B5)
4.11 TDD och databaser
TDD eller TDDD inom databaser är en relativ ny teknik att tillgå. Genom att tillämpa TDD/TDDD får databasen bättre struktur och den blir enklare att förändra. Se teorikapitlet för en utförlig beskrivning av tekniken.
Resultat: Kommande tema är relativt nytt inom TDD. Första frågan vi ställde till våra respondenter handlade om regressionstestning av databaser och varför de använde det.
Respondenten B svarade att han regressionstestade sina databaser för att vara säker så att hans kod fungerade mot databasen. Respondenten 1 på företag A och respondenterna 4, 5, 6 på företag B ser regressionstestning som en självklarhet då databasen är en del av mjukvaran som måste testas.
”Jag skriver ofta integrationstester som går genom hela applikationen inklusive databasen. Ibland även enskilda tester som testar t ex att en stored procedure fungerar som den ska” (A1)
En annan fråga som vi ställde liknade frågan som ställdes tidigare under intervjun och handlar återigen om omfaktorering. Den här gången handlade frågan om huruvida respondenterna använder sig av omfaktorering av själva databasen. På den frågan svarade respondenten B5
”nej” eftersom han ansåg det vara för riskabelt att designa om scheman i deras nuvarande
