{"id":21406,"date":"2021-08-27T10:54:28","date_gmt":"2021-08-27T08:54:28","guid":{"rendered":"https:\/\/www.software-developer-india.com\/hvad-er-testdrevet-udvikling-eller-tdd\/"},"modified":"2021-08-27T10:54:29","modified_gmt":"2021-08-27T08:54:29","slug":"hvad-er-testdrevet-udvikling-eller-tdd","status":"publish","type":"post","link":"https:\/\/www.software-developer-india.com\/da\/hvad-er-testdrevet-udvikling-eller-tdd\/","title":{"rendered":"Hvad er testdrevet udvikling? Eller TDD?"},"content":{"rendered":"\n

Hvad er testdrevet udvikling? Eller TDD?<\/h2>\n\n
\"\"<\/a><\/figure><\/div>\n\n

Test Driven Development eller TDD, som det med gl\u00e6de er kendt i udviklerkredse, er et vigtigt aspekt af softwareudviklingsprocessen. Gennem denne tilgang er det lettere at teste, hvad en bestemt kode ville udf\u00f8re. Testcases for hver funktionalitet i softwareapplikationen oprettes, og n\u00e5r en bestemt funktionalitet mislykkes i en test, vil koden blive omarbejdet, og nye koder ville blive oprettet. Den nye kode skulle ogs\u00e5 best\u00e5 testen og v\u00e6re fejlfri. Udvikleren skal kun skrive en ny kode, hvis den automatiske test for koden mislykkedes, s\u00e5 der vil v\u00e6re en testcase for hver funktionalitet, hvor lille den end er. Og TDD handler om at designe og udvikle tests for hver enkelt funktionalitet i applikationen. <\/p>\n\n

Navnet Test Driven Development indikerer, at det er processen med at lave test p\u00e5 den rigtige m\u00e5de, der driver softwareudviklingen. Derfor stammer selve processen fra r\u00f8dderne fra Agile metodik og ekstrem programmering. Denne proces sikrer, at udviklere opretter og vedligeholder kode, der er modstandsdygtig og langsigtet. <\/p>\n\n

S\u00e5 processen for TDD ville v\u00e6re at skrive enhedstesten f\u00f8rst, og hvis testen mislykkes, implementer derefter kode\u00e6ndringerne. Dette hj\u00e6lper ogs\u00e5 med at undg\u00e5 kopiering af kode. Det hele k\u00f8rer p\u00e5 at skrive og rette fejlede test f\u00f8r selve udviklingen. For at TDD’en skulle fungere med succes, ville det imidlertid v\u00e6re tilr\u00e5deligt at skrive testcases til simple testcases. For kompleks forretningslogik ville det v\u00e6re virkelig sv\u00e6rt at skrive en kombination af testcases og opn\u00e5 fuld succes. Der er en chance for, at du m\u00e5ske g\u00e5r glip af at skrive nogle tests, s\u00e5 det er slet ikke en let opgave. <\/p>\n\n

Forskel mellem TDD og traditionel testning<\/strong><\/h3>\n\n

Traditionel test er mere tidskr\u00e6vende end TDD, og er baseret p\u00e5 gentagelse af en kort udviklingscyklus. F\u00f8rst skrives testen fra begyndelsen, derefter skrives programkoden efterfulgt af systemets \u00f8nskede adf\u00e6rd. N\u00e5r den skriftlige test er best\u00e5et (kontrol af korrektheden af den uskrevne kodes arbejde), udf\u00f8res refaktorering af den skrevne kode. <\/p>\n\n

I f\u00f8rste omgang vil TDD ogs\u00e5 v\u00e6re tidskr\u00e6vende, men med tiden vil udvikleren v\u00e6nne sig til det, fordi udviklingsprocessen bliver mere struktureret. N\u00e5r du f.eks. Ans\u00e6tter en udvikler, beslutter de, hvad de skal skrive, og derefter hvordan de skal skrive det. <\/p>\n\n

Traditionel test er vellykket, n\u00e5r den korrekt finder en eller flere fejl. Ligesom det samme som TDD. At finde fejl er faktisk et godt tegn, for s\u00e5 ved du, at du skal l\u00f8se, hvad der er galt, og komme videre derfra.TDD giver dig ogs\u00e5 mere tillid, n\u00e5r du frigiver programmet, og sikrer, at det opfylder de krav, som det er defineret til. <\/p>\n\n

I traditionel test er fokus mere p\u00e5 testkassedesign, mens der i TDD er mere fokus p\u00e5 produktionskode for at verificere, om testen fungerer efter planen. <\/p>\n\n

TDD giver dig 100% testd\u00e6kning, hvor der testes for hver enkelt kodelinje, det er ikke tilf\u00e6ldet med traditionel testning.<\/p>\n\n

N\u00e5r projektets omfang er virkelig stort, skal du v\u00e6re virkelig grundig, mens du udf\u00f8rer testene. Og der er en chance for, at testen kan blive forsinket og overskride budget- og tidsbegr\u00e6nsningerne. <\/p>\n\n

TDD kan v\u00e6re sv\u00e6rt at skrive, og det kan bremse udviklingstiden, men det ville helt sikkert betale sig i det lange l\u00f8b. <\/p>\n\n

En anden ulempe med TDD er, at konceptet er sv\u00e6rt at anvende p\u00e5 eksisterende \u00e6ldre kode. <\/p>\n\n

Det er altid godt at f\u00e5 testen til at mislykkes, f\u00f8r du frigiver et projekt, for s\u00e5 ved du, at du har k\u00f8rt en gyldig test. Gennem TDD ved du, at dit system opfylder de krav, det er designet til. S\u00e5 fokus er mere p\u00e5 produktionskode til TDD, da det sikrer, om testen fungerer korrekt. Og n\u00e5r softwaren opfylder alle de krav, der er designet til det.<\/p>\n\n

De forskellige faser af en testdrevet udvikling<\/strong><\/h3>\n\n

Der er tre forskellige faser af TDD: R\u00f8d, Gr\u00f8n og Refaktor<\/p>\n\n

F\u00f8lg denne trinorden for at sikre, at du har tests for den kode, du skriver, s\u00e5 du er n\u00f8dt til at skrive koderne for kun de tests, du laver. <\/p>\n\n

Den r\u00f8de scene<\/strong><\/h3>\n\n

Ideen med den r\u00f8de fase er at f\u00e5 testen til at mislykkes, og den sv\u00e6reste fase, fordi den udvikler sig, skal skrive test mod ingen kode. Nye udviklere m\u00e5 finde det sv\u00e6rt, fordi de ville v\u00e6re forvirrede med hensyn til, hvad de skal teste uden at have koden til det. Men det er en s\u00e6dvanlig ting og med erfaring bliver det glat. Den f\u00f8rste test skrives uden at skrive kode, og for at erkl\u00e6re klasse og metode, og testen vil have kompilationsfejl. Det n\u00e6ste trin ville v\u00e6re at rette kompilationsfejlen og udf\u00f8re testen for at mislykkes. Dette for\u00e5rsager det r\u00f8de flag.<\/p>\n\n

Den gr\u00f8nne fase<\/strong><\/h3>\n\n

Efter den r\u00f8de fase ville det n\u00e6ste trin v\u00e6re at skrive koden. Denne kode skal best\u00e5 den f\u00f8rste test. Bare at skrive nok kode til at sikre, at kun den f\u00f8rste test best\u00e5r, er en forhindring mange udviklere st\u00e5r over for i starten. Fordi det i den n\u00e6ste test skulle mislykkes, efterfulgt af ny kode for at passere dem. <\/p>\n\n

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

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

I de to f\u00f8rste faser, hvor testen f\u00f8rst skal fejle og derefter best\u00e5 den, var m\u00e5let at derefter f\u00e5 testene til at best\u00e5. Men i Refractor -fasen skal andre faktorer tages i betragtning som kodekvalitet, kodevedligeholdelse, kodel\u00e6sbarhed osv. Fokus her er s\u00e5ledes p\u00e5 disse aspekter, s\u00e5 enhedstestene vil fokusere p\u00e5 dem. I refaktureringsfasen beh\u00f8ver du ikke bekymre dig om manglende funktionalitetsaspekt, for n\u00e5r kode\u00e6ndringerne sker, vil testcases automatisk ogs\u00e5 passe til funktionalitetsdelen.<\/p>\n\n

TDD passer godt ind i den agile metode<\/strong><\/h3>\n\n

Det er ganske indlysende, at projektkrav kan \u00e6ndre sig godt ind i udviklingsfasen, s\u00e5 at have TDD i samarbejde med Agile udvikling vil helt sikkert g\u00f8re det vellykket og bygge projekter, der er tilpasset kundens krav. Med testdrevet udvikling f\u00e5r du en tidligere feedback p\u00e5 projektet, som du let kan arbejde med. <\/p>\n\n

Det ville ogs\u00e5 hj\u00e6lpe med at forudse og sk\u00e6re ned p\u00e5 de kritiske flaskehalse og sikre, at projektet forts\u00e6tter efter hensigten. Udviklerhold kan spare meget tid, da testene er oprettet meget tidligere i projektudviklingen, og de skal ikke bekymre sig om omfattende test scripts. <\/p>\n\n

Konklusion<\/strong><\/h3>\n\n

Testdrevet udvikling er en teknik, der virkelig er tidskr\u00e6vende, men det er v\u00e6rdifuldt i den forstand, at det vil hj\u00e6lpe med at drive dit projekt i den rigtige retning ved at f\u00e5 korrekt feedback om projektet og opdage fejl. Det er dog en meget bedre mulighed end traditionel test, da det kr\u00e6ver mere tid og penge. <\/p>\n\n

Interessante links:<\/p>\n\n

Testdrevet udvikling: hvad det er, og hvad det ikke er.<\/a><\/p>\n\n

Flere oplysninger om testdrevet udvikling<\/a><\/p>\n\n

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

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

Forfatteren: Sascha Thattil arbejder p\u00e5 Software-Developer-India.com, som er en del af YUHIRO Group. YUHIRO er en tysk-indisk virksomhed, der leverer programm\u00f8rer til IT-virksomheder, agenturer og IT-afdelinger.<\/p>\n