Testdriven utveckling är nuförtiden en utbredd arbetsmetod, och de påstådda fördelarna är många. Det sägs bland annat leda till mer kvalitetsmässiga system som utvecklas på kortare tid. Vissa tidigare studier har bevisat att så är fallet, samtidigt som andra studier i stället motbevisat påståendet. Det här arbetets syfte är att avgöra vilket som faktiskt stämmer, om fördelarna med testdriven utveckling är sant eller enbart en myt. För att få ett svar på frågan utvecklades ett besöksloggsystem där viss del av koden framställdes testdrivet, och viss del inte testdrivet. En erfaren utvecklare jämförde sedan de olika kodstyckena för att avgöra om det fanns något kvalitetsmässig skillnad. Utvecklaren av koden fick även reflektera över huruvida utvecklingen upplevts snabbare eller inte när den skedde testdrivet. Resultatet visade att testdriven utveckling både har sina för- och nackdelar. För utvecklaren upplevs det som tidsparande att arbeta testdrivet. Däremot indikerar studien på att kod-kvaliteten försämras jämförelsevis mot om koden inte utvecklats testdrivet. Slutsatsen som drogs var att påståendet att testdriven utveckling leder till bättre kvalité av system inte nödvändigtvis behöver vara sant. Däremot visade det sig dock upplevas som tidssparande för utvecklaren, men detta bör ses som ett sekundärt mål i systemutveckling.

<p>Att skriva enhetstester är en viktig del i nya populära systemutvecklingsmetoder som extreme programming. Med testdriven utveckling skriver man testerna innan den källkod som skall testas. Ett vanligt problem med dessa tester är att de blir beroende av delar i systemet som inte är intressant för själva testen. Mock objekt är en teknik som gör det enkelt att isolera tester från allt som inte är relaterat till det som skall testas.</p><p>Det finns två sätt att se på mock objekt. Den traditionella synen är att mock objekt skall användas som ett verktyg vid isolering av externa system. Den alternativa synen är att mock objekt är ett designverktyg som kan driva fram en bättre design i systemet. I denna uppsats utvärderas ett antal mock objekt bibliotek ur detta nyare perspektiv. Resultatet visar att det finns åtskilliga skillnader mellan biblioteken.</p>

Att skriva enhetstester är en viktig del i nya populära systemutvecklingsmetoder som extreme programming. Med testdriven utveckling skriver man testerna innan den källkod som skall testas. Ett vanligt problem med dessa tester är att de blir beroende av delar i systemet som inte är intressant för själva testen. Mock objekt är en teknik som gör det enkelt att isolera tester från allt som inte är relaterat till det som skall testas. Det finns två sätt att se på mock objekt. Den traditionella synen är att mock objekt skall användas som ett verktyg vid isolering av externa system. Den alternativa synen är att mock objekt är ett designverktyg som kan driva fram en bättre design i systemet. I denna uppsats utvärderas ett antal mock objekt bibliotek ur detta nyare perspektiv. Resultatet visar att det finns åtskilliga skillnader mellan biblioteken.

An increasing amount of companies have changed development methodology in favor of test-driven development over the last couple of years. Test-driven development means that the developer starts with producing test cases, which fails. Then the functionality, for making the test cases, true is developed and finally the code is refactored. In theory, this work method minimizes the code, which fulfills the demands. A lot of studies have been conducted in order to decide pros and cons with test-driven development and compare it with other methods. However, no study has been completed with the aim of determining the prerequisites that are needed to conduct test-driven development. The aim of this study is to determine these prerequisites by performing a case study, on a large company from Sweden, in which interviews is the essential part, and a literature study. After the completion of the case study, a list of prerequisites was created based on a comparison between the result from the case study and the literature study. The main point of the list is that the company considers the implementation of test-driven development as an investment. Another important point was to only implement TDD for new projects or for already existing TDD projects. / Fler och fler företag har de senaste åren gått över till testdriven utveckling. Testdriven utveckling går ut på att utvecklare först producerar testfall som misslyckas, för att därefter skriva kod som gör att testfallet lyckas och slutligen städa upp samt radera duplicerad funktionalitet. Detta innebär i teorin att den kod som produceras för att klara kraven är minimerad. Många studier har gjorts för att bestämma för- och nackdelar med testdriven utveckling, samt jämföra det med andra tillvägagångssätt. Däremot har ingen studie undersökt vilka förutsättningar som faktiskt krävs för att man ska kunna bedriva testdriven utveckling. Genom att utföra en fallstudie, på ett större företag från Sverige, innehållandes intervjuer samt en litteraturstudie ämnar uppsatsen bringa klarhet i vilka dessa förutsättningar är. Efter genomförande av intervjuerna och jämförelse av intervjuresultat med litteraturstudien utkristalliserade sig en lista över de förutsättningar som behöver vara uppfyllda för att en organisation, som helhet, ska kunna bedriva testdriven utveckling. Listan viktigaste punkt är att organisationen betraktar en implementering av testdriven utveckling som en investering. En annan viktig punkt var att endast bedriva TDD vid nyutveckling eller vid förvaltning av kod som tidigare utvecklats med TDD.

Inom en stor del av all systemutveckling sker testerna av systemet som sista punkt innan systemet sjösätts. Testdriven utveckling är en systemutvecklingsmetod där testerna istället skrivs först och också är det som driver utvecklingen framåt. Metoden höjs till skyarna av vissa och avfärdas omedelbart som onödigt omständig av andra. Vi vill med denna uppsats undersöka hur det ser ut i verkligheten och vilka faktorer som påverkar användandet, inlärningen och inställningen till testdriven utveckling. Vi genomförde intervjuer på tre stycken Örebrobaserade organisationer och tittade utifrån ramverket method-in-action på vilka faktorer som påverkade användningen och varför. Vi fann att utvecklarna närmade sig testdriven utveckling på väldigt olika sätt och grundade sin inställning mycket beroende på tidigare erfarenhet och inlärning – oavsett hur lång eller kort den varit. Utvecklarna förväntas ofta bedriva självstudier utanför arbetstid – något som inte alltid funkar som kunskaputvecklingsform då tiden utanför jobbet ser olika ut beroende på var i livet man är. Det finns inte heller något klart program eller best-practices att följa för att lära sig metoden i någon av organisationerna. Vi såg också att det finns tekniker utanför själva metoden som utvecklare ganska omgående behöver bli bekanta med för att kunna utveckla testdrivet: dependency injection och mock.

Syftet med vår studie har varit att utforska hur utvecklare upplever en övergång från iterativ test-sist-utveckling till testdriven utveckling. I studien refereras testdriven utveckling till som TDD, en förkortning som kommer av engelskans test-driven development. TDD är en iterativ och testfokuserad systemutvecklingsmetod. Den typ av testning som används i störst utsträckning inom TDD är enhetstester. För att gå över till ett nytt arbetssätt krävs inlärning av den nya metoden. En utmaning är också att människor tenderar att använda sig av kända metoder snarare än att prova något nytt. Vi har gjort en djupgående studie ur ett systemutvecklarperspektiv. Studien genomfördes genom att fyra utvecklare på ett IT-konsultföretag använde sig av TDD under en testperiod, i stället för den iterativa test-sist-utvecklingsmetod som de vanligtvis utövar. Före och efter testperioden intervjuades utvecklarna kring deras bakgrund, upplevelser och åsikter. Utvecklarna upplevde att TDD fungerade bra för uppgifter där det passar med enhetstester, men att TDD skulle vara svårt att köra om uppgiften de skulle göra inte var väl specificerad eller hade otydligt specificerade krav. Vi upptäckte att hur bra utvecklare förstått något stämmer inte alltid överens med hur bra de tror att de förstått något. Samt att möjligheten att spara tid är en faktor som motiverar utvecklare till vilka metodval de gör. Utvecklarna upplevde att TDD gjorde att de tänkte igenom uppgiften mer innan de började koda och gjorde att de skrev mer enhetstest, vilket i sin tur genererade flera positiva bieffekter. Utvecklarna upplevde få negativa effekter. Majoriteten av utvecklarna upplevde att de flesta utmaningarna med övergång till TDD handlade om att byta vana och tankesätt. Övriga utmaningar utvecklarna upplevde handlade om att börja med TDD för ett befintligt system. De slutsatser vi har kommit fram till stämmer överens med tidigare forskning på olika fält. Vår studie pekar därför på att allmänna teorier, exempelvis teori om olika lärstilar, förändringsledning och bildande av vanor även är applicerbart vid övergång till TDD. Utifrån våra slutsatser har vi formulerat rekommendationer till organisationer hur de kan underlätta för sina utvecklare som ska gå över till TDD. / The goal of our study has been to explore how developers experience a transition from iterative test-last development to test-driven development. In this report, test-driven development is referred to as TDD. TDD is an iterative and test-focused system development method. The type of testing most widely used in TDD is unit testing. To switch to a new working method requires learning the new method. A challenge faced is also that people tend to use known methods rather than try something new. We have done an in-depth study from a developer perspective. Four developers at an IT consulting company got to use TDD during a test period, instead of the iterative test-last development method they usually practice. Before and after the test period, the developers were interviewed about their background, experiences and opinions. The developers felt that TDD worked well for tasks where unit tests were appropriate, but that TDD would be difficult to apply if the task they were to perform was not well specified or had unclear requirements. We discovered that how well developers understand something does not always match how well they think they understand something. We also discovered that the possibility to save time is a factor that motivates developers to which method choices they make. The developers felt that TDD made them think through the task more thoroughly before they started coding and that it made them write more unit tests, which in turn generated several positive side effects. The developers experienced few negative effects. The majority of the developers felt that most of the challenges with the transition to TDD concerned changing habits and mindset. Other challenges the developers experienced concerned starting with TDD for an existing system. Our conclusions are consistent with previous research in various fields. Our study therefore indicates that general theories, such as theory of different learning styles, change management and habit formation, are also applicable in the transition to TDD. Based on our conclusions, we have formulated recommendations to organizations on how they can facilitate for their developers to transition to TDD.

Denna rapport behandlar skapandet av en webbapplikation för filtreraring och visualisering av data i Pythonramverket Dash. Rapporten ger en översikt av gruppens arbetsmetodik och projektets utveckling. Webbapplikationen utvecklades inom kursen TDDD96 Kandidatprojekt i programvaruutveckling av nio studenter som studerar civilingenjör Datateknik och civilingenjör Mjukvaruteknik. Detta uppdrag fick projektgruppen av företaget Ericsson. Projektets resultat blev en fungerade webbapplikation efterfrågad funktionalitet. Resultatet och arbetsmetodiken, bland annat testdriven utveckling, diskuteras i rapporten med fokus på hur utvecklingsprocessen förbättrades. Rapportens slutsatser är att ramverket Dash lämpar sig för webbutveckling i ett mindre projekt, särskilt för datavisualisering, och att produkten skapar värde för kunden.

Detta examensarbete har utförts på uppdrag av Stegia AB. Stegias linjärmotorerprovas i en testbänk innan motorerna skickas till den slutliga kunden. Idag finns ettbehov av en testbänk som skall samla in data från utförda tester, minska risken atttesterna utförs fel, samt att testbänken skall vara lättare att använda för produktionspersonalen.Idag innehåller linjärmotortestet många manuella arbetsmoment,vilket innebär en hög risk för felaktiga resultat utan möjlighet till spårbarhet i testresultatet.Målet med detta arbete är att förenkla det slutliga testet av linjärmotorerför produktionspersonal, samt att minska risken för felaktigt utförda tester genomtestautomatisering. Resultatet presenteras i form av en prototyp som har konstruerats,vars syfte är att förbättra test av linjärmotorerna genom att uppfylla målet atträtt utförda tester görs på motorerna. Resultatet säkerställs genom validering ochutvärdering och analys av den framtagna prototypen. / This diploma work has been carried out on behalf of Stegia AB. Stegia manufacturesand sells linear motors that are tested in a test bench before shipped to thecustomer. Today there is a need for a test bench that collects test results from theperformed tests. The company would like to lower the risk of falsely made tests,and to make the test bench easier for the production staff to use. At this moment,the test of the linear motors is made up of several manual tasks before the test iscompleted. This increases the risk of wrong results because of incorrectly madetests, with no traceability of the results. The goal with this diploma work is to lowerthe risk of incorrect test result by automating the testing process for the productionstaff. The result is presented as a prototype, that should increase the reliability ofthe test result of the motors. The result is then validated and analyzed in this report.

Test driven development [TDD] is an iterative technique where unit   tests are written before production code. General idea is that quality,   especially code design, improves with usage of TDD. Previous studies have had   difficulties proving these benefits. Qualitative studies about TDD are rare   and a deeper understanding how developers’ view relates to usage of TDD has   been sought after. How experience affects usage and perception about TDD is   of particular interest, and the study’s basis. Semi-structured interviews were conducted with three experienced and   three inexperienced developers in a qualitative survey study. Obvious   differences could be determined by letting those groups represent the   experience range that exists. A deductive thematic analysis was performed with   the help of a theoretical framework. Results show that   workplace’s culture greatly affects how TDD is used. TDD is not commonly used   and low adherence to protocol is also made visible. Differences in basic view   about TDD is evident as well – creation of the code’s design is starting   point for experienced developers, inexperienced use TDD as a tool in creation   of unit tests and to control system correctness. / Testdriven utveckling [TDD]   är en iterativ teknik där enhetstest skrivs före produktionskod. Tanken är   att kvalité och framförallt design av kod förbättras vid användning av TDD.   Tidigare studier visar svårigheter att bevisa dessa vinster. Kvalitativa   studier är ovanliga i forskning om TDD och en djupare förståelse hur TDD   används från utvecklarens synvinkel har eftersökts. Hur erfarenhet påverkar   användning och uppfattning om TDD är särskilt intressant, och fungerar som   studiens grund. Semistrukturerade   intervjuer utfördes med tre erfarna och tre oerfarna utvecklare i en   kvalitativ tvärsnittsstudie. Genom att låta grupperna representera det   erfarenhetsspann som existerar kunde tydliga skillnader synliggöras. En   deduktiv tematisk analys genomfördes med hjälp av ett teoretiskt ramverk. Studien visar framförallt   att arbetsplatsens kultur påverkar stort hur TDD används. TDD används inte i   särskilt stor utsträckning och låg regelmässighet blev även synliggjort.   Förutom detta visades skillnader i grundläggande syn över TDD – skapande av   kodens design är utgångspunkt för erfarna utvecklare, oerfarna använder TDD   som verktyg att skapa tester och kontrollera systemets korrekthet.

I detta projekt jobbar vi för att skapa ett program åt Infozone Sverige AB tillsammans med professionella utvecklare från företaget. Programmet är en webbportal som används till att övervaka och visa driftinformation om ett nätverk. Tanken är att denna portal skall integreras i ett ännu ej byggt system för nätverksövervakning som Infozone senare kan sälja till kund. Produkten tas fram med Scrum samt testdriven utveckling och under utvecklingen jobbar laget med bestämda metoder och SOLID-principerna för att säkerställa programmets kvalitet. Webbportalen utnyttjar moderna teknologier och ramverk för webbutveckling, bland annat är den en Single Page Application (SPA), använder följsam webbdesign och utnyttjar Microsofts .NET-plattform. I slutändan är inte alla ställda krav uppfyllda, men i och med att Scrum används är programmet fungerande vid projektets avslutande. De krav som faktiskt implementeras görs så till fullo. Vidare visar det sig att det inte alltid är bäst att använda de senaste ramverken, utan mer beprövade metoder och teknologier kan i vissa fall vara mer lämpliga. / In this project we are creating a program for Infozone Sverige AB together with professional developers from the company. The program is a web portal which will be used to monitor and show system status of a network. The plan is that this web portal will be integrated into a not yet built network monitoring system which Infozone later can sell to their clients. The product is developed using Scrum together with test-driven development and during the development the team is working with certain methods and the SOLID principles to ensure the quality of the program. The web portal takes advantage of modern technologies and frameworks for web development, among other things it is a Single Page Application (SPA), uses responsive design and Microsoft’s .NET platform. In the end not all requirements are met, but because we are using Scrum, the program is functioning at the end of the project. The requirements that are implemented, are fully so. Furthermore, it is shown that it is not always best to use the latest frameworks, but the more tested methods and technologies can in some cases be more appropriate.