Hvad er testdrevet udvikling? Eller TDD?

Hvad er testdrevet udvikling? Eller TDD?

Test Driven Development eller TDD, som det med glæde er kendt i udviklerkredse, er et vigtigt aspekt af softwareudviklingsprocessen. Gennem denne tilgang er det lettere at teste, hvad en bestemt kode ville udføre. Testcases for hver funktionalitet i softwareapplikationen oprettes, og når en bestemt funktionalitet mislykkes i en test, vil koden blive omarbejdet, og nye koder ville blive oprettet. Den nye kode skulle også bestå testen og være fejlfri. Udvikleren skal kun skrive en ny kode, hvis den automatiske test for koden mislykkedes, så der vil være 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.

Navnet Test Driven Development indikerer, at det er processen med at lave test på den rigtige måde, der driver softwareudviklingen. Derfor stammer selve processen fra rødderne fra Agile metodik og ekstrem programmering. Denne proces sikrer, at udviklere opretter og vedligeholder kode, der er modstandsdygtig og langsigtet.

Så processen for TDD ville være at skrive enhedstesten først, og hvis testen mislykkes, implementer derefter kodeændringerne. Dette hjælper også med at undgå kopiering af kode. Det hele kører på at skrive og rette fejlede test før selve udviklingen. For at TDD’en skulle fungere med succes, ville det imidlertid være tilrådeligt at skrive testcases til simple testcases. For kompleks forretningslogik ville det være virkelig svært at skrive en kombination af testcases og opnå fuld succes. Der er en chance for, at du måske går glip af at skrive nogle tests, så det er slet ikke en let opgave.

Forskel mellem TDD og traditionel testning

Traditionel test er mere tidskrævende end TDD, og er baseret på gentagelse af en kort udviklingscyklus. Først skrives testen fra begyndelsen, derefter skrives programkoden efterfulgt af systemets ønskede adfærd. Når den skriftlige test er bestået (kontrol af korrektheden af den uskrevne kodes arbejde), udføres refaktorering af den skrevne kode.

I første omgang vil TDD også være tidskrævende, men med tiden vil udvikleren vænne sig til det, fordi udviklingsprocessen bliver mere struktureret. Når du f.eks. Ansætter en udvikler, beslutter de, hvad de skal skrive, og derefter hvordan de skal skrive det.

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

I traditionel test er fokus mere på testkassedesign, mens der i TDD er mere fokus på produktionskode for at verificere, om testen fungerer efter planen.

TDD giver dig 100% testdækning, hvor der testes for hver enkelt kodelinje, det er ikke tilfældet med traditionel testning.

Når projektets omfang er virkelig stort, skal du være virkelig grundig, mens du udfører testene. Og der er en chance for, at testen kan blive forsinket og overskride budget- og tidsbegrænsningerne.

TDD kan være svært at skrive, og det kan bremse udviklingstiden, men det ville helt sikkert betale sig i det lange løb.

En anden ulempe med TDD er, at konceptet er svært at anvende på eksisterende ældre kode.

Det er altid godt at få testen til at mislykkes, før du frigiver et projekt, for så ved du, at du har kørt en gyldig test. Gennem TDD ved du, at dit system opfylder de krav, det er designet til. Så fokus er mere på produktionskode til TDD, da det sikrer, om testen fungerer korrekt. Og når softwaren opfylder alle de krav, der er designet til det.

De forskellige faser af en testdrevet udvikling

Der er tre forskellige faser af TDD: Rød, Grøn og Refaktor

Følg denne trinorden for at sikre, at du har tests for den kode, du skriver, så du er nødt til at skrive koderne for kun de tests, du laver.

Den røde scene

Ideen med den røde fase er at få testen til at mislykkes, og den sværeste fase, fordi den udvikler sig, skal skrive test mod ingen kode. Nye udviklere må finde det svært, fordi de ville være forvirrede med hensyn til, hvad de skal teste uden at have koden til det. Men det er en sædvanlig ting og med erfaring bliver det glat. Den første test skrives uden at skrive kode, og for at erklære klasse og metode, og testen vil have kompilationsfejl. Det næste trin ville være at rette kompilationsfejlen og udføre testen for at mislykkes. Dette forårsager det røde flag.

Den grønne fase

Efter den røde fase ville det næste trin være at skrive koden. Denne kode skal bestå den første test. Bare at skrive nok kode til at sikre, at kun den første test består, er en forhindring mange udviklere står over for i starten. Fordi det i den næste test skulle mislykkes, efterfulgt af ny kode for at passere dem.

Refraktor -fasen

I de to første faser, hvor testen først skal fejle og derefter bestå den, var målet at derefter få testene til at bestå. Men i Refractor -fasen skal andre faktorer tages i betragtning som kodekvalitet, kodevedligeholdelse, kodelæsbarhed osv. Fokus her er således på disse aspekter, så enhedstestene vil fokusere på dem. I refaktureringsfasen behøver du ikke bekymre dig om manglende funktionalitetsaspekt, for når kodeændringerne sker, vil testcases automatisk også passe til funktionalitetsdelen.

TDD passer godt ind i den agile metode

Det er ganske indlysende, at projektkrav kan ændre sig godt ind i udviklingsfasen, så at have TDD i samarbejde med Agile udvikling vil helt sikkert gøre det vellykket og bygge projekter, der er tilpasset kundens krav. Med testdrevet udvikling får du en tidligere feedback på projektet, som du let kan arbejde med.

Det ville også hjælpe med at forudse og skære ned på de kritiske flaskehalse og sikre, at projektet fortsætter 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.

Konklusion

Testdrevet udvikling er en teknik, der virkelig er tidskrævende, men det er værdifuldt i den forstand, at det vil hjælpe med at drive dit projekt i den rigtige retning ved at få korrekt feedback om projektet og opdage fejl. Det er dog en meget bedre mulighed end traditionel test, da det kræver mere tid og penge.

Interessante links:

Testdrevet udvikling: hvad det er, og hvad det ikke er.

Flere oplysninger om testdrevet udvikling

Billeder: Canva

Forfatteren: Sascha Thattil arbejder på Software-Developer-India.com, som er en del af YUHIRO Group. YUHIRO er en tysk-indisk virksomhed, der leverer programmører til IT-virksomheder, agenturer og IT-afdelinger.