Hva er testdrevet utvikling? Eller TDD?

Hva er testdrevet utvikling? Eller TDD?

Test Driven Development eller TDD som det er kjent i utviklerkretsene, er et viktig aspekt av programvareutviklingsprosessen. Gjennom denne tilnærmingen er det lettere å teste hva en bestemt kode ville utføre. Testtilfeller for hver funksjonalitet i programmet opprettes, og når en bestemt funksjonalitet mislykkes i en test, vil koden bli bearbeidet på nytt og nye koder vil bli opprettet. Den nye koden må også bestå testen og være feilfri. Utvikleren må skrive en ny kode bare hvis den automatiske testen for koden mislyktes, så det vil være et testtilfelle for hver funksjonalitet, hvor liten den enn måtte være. Og TDD handler om å designe og utvikle tester for hver enkelt funksjonalitet i applikasjonen.

Navnet Test Driven Development indikerer at det er prosessen med å gjøre tester på riktig måte som driver programvareutviklingen. Derfor stammer selve prosessen fra røttene fra Agile metodikk og ekstrem programmering. Denne prosessen sikrer at utviklere oppretter og vedlikeholder kode som er motstandsdyktig og langsiktig.

Så prosessen for TDD ville være å skrive enhetstesten først, og hvis testen mislykkes, implementer deretter kodeendringene. Dette hjelper også med å unngå duplisering av kode. Det hele går på å skrive og korrigere mislykkede tester før selve utviklingen. For at TDD skal fungere vellykket, vil det imidlertid være tilrådelig å skrive testtilfellene til enkle testtilfeller. For kompleks forretningslogikk ville det være veldig tøft å skrive en kombinasjon av testcases og oppnå full suksess. Det er en sjanse for at du går glipp av å skrive noen tester, så det er ikke en lett oppgave i det hele tatt.

Forskjell mellom TDD og tradisjonell testing

Tradisjonell testing er mer tidkrevende enn TDD, og er basert på gjentagelse av en kort utviklingssyklus. Først skrives testen fra begynnelsen, deretter skrives programkoden, etterfulgt av systemets ønskede oppførsel. Når den skriftlige testen er bestått (kontroll av korrektheten i den uskrevne kodens arbeid), utføres refaktorering av den skrevne koden.

I utgangspunktet vil TDD også være tidkrevende, men over tid vil utvikleren bli vant til det fordi utviklingsprosessen vil bli mer strukturert. For eksempel, når du ansetter en utvikler, vil de bestemme hva de skal skrive, og deretter hvordan de skal skrive det.

Tradisjonell testing er vellykket når den finner en eller flere feil korrekt. Akkurat det samme som TDD. Å finne feil er faktisk et godt tegn, for da vet du at du må løse det som er galt og gå videre derfra. TDD gir deg også mer tillit når du slipper programmet, og sikrer at det oppfyller kravene det er definert for.

I tradisjonell testing er fokuset mer på testkassedesign, mens i TDD er fokuset mer på produksjonskode for å bekrefte om testen vil fungere etter planen.

TDD gir deg 100% testdekning, hvor testing utføres for hver enkelt kodelinje, det er ikke tilfelle med tradisjonell testing.

Når prosjektomfanget er veldig stort, må du være grundig mens du utfører testene. Og det er en sjanse for at testen kan bli forsinket og krysse budsjettet og tidsbegrensningene.

TDD kan være vanskelig å skrive, og det kan bremse utviklingstiden, men det vil definitivt lønne seg i det lange løp.

En annen ulempe med TDD er at konseptet er vanskelig å bruke på eksisterende eldre kode.

Det er alltid godt å ha testen til å mislykkes før du slipper et prosjekt, for da vet du at du har kjørt en gyldig test. Gjennom TDD vil du vite at systemet ditt oppfyller kravene det er designet for. Så fokuset er mer på produksjonskode for TDD, da det sikrer om testen vil fungere skikkelig. Og når programvaren oppfyller alle kravene som er designet for den.

De forskjellige stadiene av en testdrevet utvikling

Det er tre forskjellige stadier av TDD: Rød, Grønn og Refactor

Følg denne trinnene for å sikre at du har tester for koden du skriver, så du må skrive kodene for bare de testene du gjør.

Den røde scenen

Ideen med det røde stadiet er å få testen til å mislykkes, og den vanskeligste fasen også fordi den utvikler seg må skrive test mot ingen kode. Nye utviklere må finne det vanskelig fordi de ville være forvirret om hva de skal teste uten å ha koden for det. Men det er en vanlig ting, og med erfaring vil det bli jevnt. Den første testen skrives uten å skrive kode, og for å deklarere klasse og metode, og testen vil ha en kompilasjonsfeil. Det neste trinnet vil være å fikse kompileringsfeilen, og utføre testen for å mislykkes. Dette forårsaker det røde flagget.

Den grønne fasen

Etter den røde fasen, ville det neste trinnet være å skrive koden. Denne koden må bestå den første testen. Bare å skrive nok kode for å sikre at bare den første testen består, er en hindring mange utviklere står overfor i utgangspunktet. Fordi det i den neste testen måtte mislykkes, etterfulgt av ny kode for å passere dem.

Refractor -fasen

I de to første stadiene, der testen først må mislykkes, og deretter bestå den, var målet å deretter få testene til å bestå. Men i Refractor -fasen må andre faktorer tas i betraktning som kodekvalitet, kodevedlikehold, kodelesbarhet etc. Fokuset her er dermed på disse aspektene, så enhetstestene vil fokusere på disse. I refaktoreringsfasen trenger du ikke bekymre deg for manglende funksjonalitetsaspekt, for når kodeendringene skjer, vil testtilfellene automatisk også samsvare med funksjonalitetsdelen.

TDD passer godt inn i Agile -metodikken

Det er ganske åpenbart at prosjektkrav kan endres godt inn i utviklingsstadiet, så det å ha TDD i samarbeid med Agile utvikling vil definitivt gjøre det vellykket og bygge prosjekter som er tilpasset kundens krav. Med testdrevet utvikling får du en tidligere tilbakemelding på prosjektet som du enkelt kan jobbe med.

Det vil også bidra til å forutse og kutte ned på de kritiske flaskehalsene og sikre at prosjektet fortsetter etter hensikten. Utviklerteam kan spare mye tid ettersom testene blir opprettet mye tidligere i prosjektutviklingen, og de trenger ikke å bekymre seg for omfattende testskript.

Konklusjon

Testdrevet utvikling er en teknikk som faktisk er tidkrevende, men den er verdifull i den forstand at den vil bidra til å drive prosjektet i riktig retning ved å få riktig tilbakemelding om prosjektet og oppdage feil. Det er imidlertid et mye bedre alternativ enn tradisjonell testing, da det krever mer tid og penger.

Interessante lenker:

Testdrevet utvikling: hva det er, og hva det ikke er.

Mer informasjon om testdrevet utvikling

Bilder: Canva

Forfatteren: Sascha Thattil jobber på Software-Developer-India.com som er en del av YUHIRO Group. YUHIRO er en tysk-indisk bedrift som tilbyr programmerere til IT-selskaper, byråer og IT-avdelinger.