{"id":21438,"date":"2021-08-27T11:05:07","date_gmt":"2021-08-27T09:05:07","guid":{"rendered":"https:\/\/www.software-developer-india.com\/vad-ar-testdriven-utveckling-eller-tdd\/"},"modified":"2021-08-27T11:05:11","modified_gmt":"2021-08-27T09:05:11","slug":"vad-ar-testdriven-utveckling-eller-tdd","status":"publish","type":"post","link":"https:\/\/www.software-developer-india.com\/sv\/vad-ar-testdriven-utveckling-eller-tdd\/","title":{"rendered":"Vad \u00e4r testdriven utveckling? Eller TDD?"},"content":{"rendered":"\n

Vad \u00e4r testdriven utveckling? Eller TDD?<\/h2>\n\n
\"\"<\/a><\/figure><\/div>\n\n

Test Driven Development eller TDD som det \u00e4r k\u00e4nt i utvecklarkretsarna \u00e4r en viktig aspekt av mjukvaruutvecklingsprocessen. Genom detta tillv\u00e4gag\u00e5ngss\u00e4tt \u00e4r det l\u00e4ttare att testa vad en specifik kod skulle utf\u00f6ra. Testfall f\u00f6r varje funktionalitet i programvaran skapas, och n\u00e4r en viss funktionalitet misslyckas i ett test skulle koden omarbetas och nya koder skapas. Den nya koden m\u00e5ste ocks\u00e5 klara testet och vara buggfri. Utvecklaren m\u00e5ste bara skriva en ny kod om det automatiska testet f\u00f6r koden har misslyckats, s\u00e5 det kommer att finnas ett testfall f\u00f6r varje funktionalitet, hur liten som helst. Och TDD handlar om att designa och utveckla tester f\u00f6r varje funktion i applikationen. <\/p>\n\n

Namnet Test Driven Development indikerar att det \u00e4r processen att g\u00f6ra tester p\u00e5 r\u00e4tt s\u00e4tt som driver mjukvaruutvecklingen. D\u00e4rf\u00f6r h\u00e4rstammar sj\u00e4lva processen fr\u00e5n Agile metodik och extrem programmering. Denna process s\u00e4kerst\u00e4ller att utvecklare skapar och underh\u00e5ller kod som \u00e4r motst\u00e5ndskraftig och l\u00e5ngsiktig. <\/p>\n\n

S\u00e5 processen f\u00f6r TDD skulle vara att skriva enhetstestet f\u00f6rst, och om testet misslyckas, implementera sedan kod\u00e4ndringarna. Detta hj\u00e4lper ocks\u00e5 till att undvika dubblering av kod. Det hela g\u00e5r p\u00e5 att skriva och korrigera misslyckade tester innan sj\u00e4lva utvecklingen. F\u00f6r att TDD ska fungera framg\u00e5ngsrikt \u00e4r det dock l\u00e4mpligt att skriva testfallen till enkla testfall. F\u00f6r komplex aff\u00e4rslogik skulle det vara riktigt sv\u00e5rt att skriva en kombination av testfall och uppn\u00e5 full framg\u00e5ng. Det finns en chans att du kanske missar att skriva n\u00e5gra tester, s\u00e5 det \u00e4r inte en l\u00e4tt uppgift alls. <\/p>\n\n

Skillnad mellan TDD och traditionell testning<\/strong><\/h3>\n\n

Traditionell testning \u00e4r mer tidskr\u00e4vande \u00e4n TDD och baseras p\u00e5 upprepningen av en kort utvecklingscykel. F\u00f6rst skrivs testet fr\u00e5n b\u00f6rjan, sedan skrivs programkoden, f\u00f6ljt av systemets \u00f6nskade beteende. N\u00e4r det skriftliga testet har godk\u00e4nts (kontroll av att den oskrivna kodens arbete \u00e4r korrekt) utf\u00f6rs refaktorering av den skrivna koden. <\/p>\n\n

Inledningsvis kommer TDD ocks\u00e5 att vara tidskr\u00e4vande, men med tiden kommer utvecklaren att v\u00e4nja sig vid det eftersom utvecklingsprocessen kommer att bli mer strukturerad. Till exempel, n\u00e4r du anlitar en utvecklare kommer de att best\u00e4mma vad de ska skriva och sedan hur de ska skriva det. <\/p>\n\n

Traditionell testning \u00e4r framg\u00e5ngsrik n\u00e4r den korrekt hittar en eller flera defekter. Precis som TDD. Att hitta defekter \u00e4r faktiskt ett bra tecken f\u00f6r d\u00e5 vet du att du m\u00e5ste l\u00f6sa vad som \u00e4r fel och g\u00e5 vidare d\u00e4rifr\u00e5n. TDD ger dig ocks\u00e5 mer sj\u00e4lvf\u00f6rtroende n\u00e4r du sl\u00e4pper programmet och ser till att det uppfyller de krav som det definieras f\u00f6r. <\/p>\n\n

I traditionell testning \u00e4r fokus mer p\u00e5 testfallets design, medan i TDD \u00e4r fokus mer p\u00e5 produktionskod f\u00f6r att verifiera om testet fungerar enligt planen. <\/p>\n\n

TDD ger dig 100% testt\u00e4ckning, d\u00e4r testning g\u00f6rs f\u00f6r varje kodrad, det \u00e4r inte fallet med traditionell testning.<\/p>\n\n

N\u00e4r projektomf\u00e5nget \u00e4r riktigt stort m\u00e5ste du vara riktigt noggrann n\u00e4r du utf\u00f6r testerna. Och det finns en chans att testet kan bli f\u00f6rsenat och passera budgeten och tidsbegr\u00e4nsningarna. <\/p>\n\n

TDD kan vara sv\u00e5rt att skriva, och det kan bromsa utvecklingstiden, men det skulle definitivt l\u00f6na sig i l\u00e4ngden. <\/p>\n\n

En annan nackdel med TDD \u00e4r att konceptet \u00e4r sv\u00e5rt att till\u00e4mpa p\u00e5 befintlig \u00e4ldre kod. <\/p>\n\n

Det \u00e4r alltid bra att testet misslyckas innan du sl\u00e4pper ett projekt, f\u00f6r d\u00e5 vet du att du har k\u00f6rt ett giltigt test. Genom TDD vet du att ditt system uppfyller de krav som det \u00e4r utformat f\u00f6r. S\u00e5 fokus ligger mer p\u00e5 produktionskod f\u00f6r TDD, eftersom det s\u00e4kerst\u00e4ller om testet kommer att fungera korrekt. Och n\u00e4r programvaran uppfyller alla krav som \u00e4r avsedda f\u00f6r den.<\/p>\n\n

De olika stadierna i en testdriven utveckling<\/strong><\/h3>\n\n

Det finns tre olika stadier av TDD: R\u00f6d, gr\u00f6n och Refactor<\/p>\n\n

F\u00f6lj denna stegordning s\u00e4kerst\u00e4ller att du har tester f\u00f6r koden du skriver, s\u00e5 du m\u00e5ste bara skriva koder f\u00f6r de tester du g\u00f6r. <\/p>\n\n

Den r\u00f6da scenen<\/strong><\/h3>\n\n

Tanken med det r\u00f6da stadiet \u00e4r att f\u00e5 testet att misslyckas, och den sv\u00e5raste fasen ocks\u00e5 eftersom den utvecklas m\u00e5ste skriva test mot ingen kod. Nya utvecklare m\u00e5ste ha sv\u00e5rt eftersom de skulle vara f\u00f6rvirrade om vad de ska testa utan att ha koden f\u00f6r det. Men det \u00e4r en vanlig sak och med erfarenhet kommer det att bli smidigt. Det f\u00f6rsta testet skrivs utan att skriva kod och f\u00f6r att deklarera klass och metod, och testet kommer att ha kompileringsfel. N\u00e4sta steg skulle vara att fixa kompileringsfelet och k\u00f6ra testet f\u00f6r att misslyckas. Detta orsakar den r\u00f6da flaggan.<\/p>\n\n

Den gr\u00f6na fasen<\/strong><\/h3>\n\n

Efter det r\u00f6da steget skulle n\u00e4sta steg vara att skriva koden. Denna kod m\u00e5ste klara det f\u00f6rsta testet. Att bara skriva tillr\u00e4ckligt med kod f\u00f6r att se till att bara det f\u00f6rsta testet klarar sig \u00e4r ett hinder som m\u00e5nga utvecklare st\u00e5r inf\u00f6r. F\u00f6r i n\u00e4sta test m\u00e5ste det misslyckas, f\u00f6ljt av ny kod f\u00f6r att skicka dem. <\/p>\n\n

\"\"<\/a><\/figure><\/div>\n\n

Refraktor -fasen<\/strong><\/h3>\n\n

I de tv\u00e5 f\u00f6rsta stadierna, d\u00e4r testet f\u00f6rst m\u00e5ste misslyckas och sedan klara det, var m\u00e5let att sedan f\u00e5 testerna att klara. Men i Refractor -fasen m\u00e5ste andra faktorer beaktas som kodkvalitet, kodunderh\u00e5llbarhet, kodl\u00e4sbarhet etc. Fokus h\u00e4r \u00e4r allts\u00e5 p\u00e5 dessa aspekter, s\u00e5 enhetstesterna kommer att fokusera p\u00e5 dessa. I ombyggnadsfasen beh\u00f6ver du inte oroa dig f\u00f6r saknad funktionalitetsaspekt, f\u00f6r n\u00e4r kod\u00e4ndringarna sker kommer testfallen automatiskt att \u00f6verensst\u00e4mma med funktionalitetsdelen ocks\u00e5.<\/p>\n\n

TDD passar v\u00e4l in i Agile -metodiken<\/strong><\/h3>\n\n

Det \u00e4r helt uppenbart att projektkraven kan \u00e4ndras l\u00e5ngt in i utvecklingsstadiet, s\u00e5 att ha TDD i samarbete med Agile utveckling kommer definitivt att g\u00f6ra det framg\u00e5ngsrikt och bygga projekt som \u00e4r anpassade till kundernas krav. Med testdriven utveckling f\u00e5r du en tidigare feedback p\u00e5 projektet som du enkelt kan arbeta med. <\/p>\n\n

Det skulle ocks\u00e5 hj\u00e4lpa till att f\u00f6rutse och minska de kritiska flaskhalsarna och s\u00e4kerst\u00e4lla att projektet g\u00e5r vidare som avsett. Utvecklarteam kan spara mycket tid eftersom testerna skapas mycket tidigare i projektutvecklingen, och de beh\u00f6ver inte oroa sig f\u00f6r omfattande testskript. <\/p>\n\n

Slutsats<\/strong><\/h3>\n\n

Testdriven utveckling \u00e4r en teknik som verkligen \u00e4r tidskr\u00e4vande, men den \u00e4r v\u00e4rdefull i den meningen att den hj\u00e4lper till att driva ditt projekt i r\u00e4tt riktning genom att f\u00e5 korrekt feedback om projektet och uppt\u00e4cka buggar. Det \u00e4r dock ett mycket b\u00e4ttre alternativ \u00e4n traditionella tester eftersom det kr\u00e4ver mer tid och pengar. <\/p>\n\n

Intressanta l\u00e4nkar:<\/p>\n\n

Testdriven utveckling: vad det \u00e4r och vad det inte \u00e4r.<\/a><\/p>\n\n

Mer information om testdriven utveckling<\/a><\/p>\n\n

Bilder: Canva<\/p>\n\n

\"\"<\/figure><\/div>\n\n

F\u00f6rfattaren: Sascha Thattil arbetar p\u00e5 Software-Developer-India.com som \u00e4r en del av YUHIRO Group. YUHIRO \u00e4r ett tysk-indiskt f\u00f6retag som tillhandah\u00e5ller programmerare till IT-f\u00f6retag, byr\u00e5er och IT-avdelningar.<\/p>\n