{"id":21432,"date":"2021-08-27T11:03:52","date_gmt":"2021-08-27T09:03:52","guid":{"rendered":"https:\/\/www.software-developer-india.com\/hva-er-testdrevet-utvikling-eller-tdd\/"},"modified":"2021-08-27T11:04:02","modified_gmt":"2021-08-27T09:04:02","slug":"hva-er-testdrevet-utvikling-eller-tdd","status":"publish","type":"post","link":"https:\/\/www.software-developer-india.com\/no\/hva-er-testdrevet-utvikling-eller-tdd\/","title":{"rendered":"Hva er testdrevet utvikling? Eller TDD?"},"content":{"rendered":"\n

Hva er testdrevet utvikling? Eller TDD?<\/h2>\n\n
\"\"<\/a><\/figure><\/div>\n\n

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

Navnet Test Driven Development indikerer at det er prosessen med \u00e5 gj\u00f8re tester p\u00e5 riktig m\u00e5te som driver programvareutviklingen. Derfor stammer selve prosessen fra r\u00f8ttene fra Agile metodikk og ekstrem programmering. Denne prosessen sikrer at utviklere oppretter og vedlikeholder kode som er motstandsdyktig og langsiktig. <\/p>\n\n

S\u00e5 prosessen for TDD ville v\u00e6re \u00e5 skrive enhetstesten f\u00f8rst, og hvis testen mislykkes, implementer deretter kodeendringene. Dette hjelper ogs\u00e5 med \u00e5 unng\u00e5 duplisering av kode. Det hele g\u00e5r p\u00e5 \u00e5 skrive og korrigere mislykkede tester f\u00f8r selve utviklingen. For at TDD skal fungere vellykket, vil det imidlertid v\u00e6re tilr\u00e5delig \u00e5 skrive testtilfellene til enkle testtilfeller. For kompleks forretningslogikk ville det v\u00e6re veldig t\u00f8ft \u00e5 skrive en kombinasjon av testcases og oppn\u00e5 full suksess. Det er en sjanse for at du g\u00e5r glipp av \u00e5 skrive noen tester, s\u00e5 det er ikke en lett oppgave i det hele tatt. <\/p>\n\n

Forskjell mellom TDD og tradisjonell testing<\/strong><\/h3>\n\n

Tradisjonell testing er mer tidkrevende enn TDD, og er basert p\u00e5 gjentagelse av en kort utviklingssyklus. F\u00f8rst skrives testen fra begynnelsen, deretter skrives programkoden, etterfulgt av systemets \u00f8nskede oppf\u00f8rsel. N\u00e5r den skriftlige testen er best\u00e5tt (kontroll av korrektheten i den uskrevne kodens arbeid), utf\u00f8res refaktorering av den skrevne koden. <\/p>\n\n

I utgangspunktet vil TDD ogs\u00e5 v\u00e6re tidkrevende, men over tid vil utvikleren bli vant til det fordi utviklingsprosessen vil bli mer strukturert. For eksempel, n\u00e5r du ansetter en utvikler, vil de bestemme hva de skal skrive, og deretter hvordan de skal skrive det. <\/p>\n\n

Tradisjonell testing er vellykket n\u00e5r den finner en eller flere feil korrekt. Akkurat det samme som TDD. \u00c5 finne feil er faktisk et godt tegn, for da vet du at du m\u00e5 l\u00f8se det som er galt og g\u00e5 videre derfra. TDD gir deg ogs\u00e5 mer tillit n\u00e5r du slipper programmet, og sikrer at det oppfyller kravene det er definert for. <\/p>\n\n

I tradisjonell testing er fokuset mer p\u00e5 testkassedesign, mens i TDD er fokuset mer p\u00e5 produksjonskode for \u00e5 bekrefte om testen vil fungere etter planen. <\/p>\n\n

TDD gir deg 100% testdekning, hvor testing utf\u00f8res for hver enkelt kodelinje, det er ikke tilfelle med tradisjonell testing.<\/p>\n\n

N\u00e5r prosjektomfanget er veldig stort, m\u00e5 du v\u00e6re grundig mens du utf\u00f8rer testene. Og det er en sjanse for at testen kan bli forsinket og krysse budsjettet og tidsbegrensningene. <\/p>\n\n

TDD kan v\u00e6re vanskelig \u00e5 skrive, og det kan bremse utviklingstiden, men det vil definitivt l\u00f8nne seg i det lange l\u00f8p. <\/p>\n\n

En annen ulempe med TDD er at konseptet er vanskelig \u00e5 bruke p\u00e5 eksisterende eldre kode. <\/p>\n\n

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

De forskjellige stadiene av en testdrevet utvikling<\/strong><\/h3>\n\n

Det er tre forskjellige stadier av TDD: R\u00f8d, Gr\u00f8nn og Refactor<\/p>\n\n

F\u00f8lg denne trinnene for \u00e5 sikre at du har tester for koden du skriver, s\u00e5 du m\u00e5 skrive kodene for bare de testene du gj\u00f8r. <\/p>\n\n

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

Ideen med det r\u00f8de stadiet er \u00e5 f\u00e5 testen til \u00e5 mislykkes, og den vanskeligste fasen ogs\u00e5 fordi den utvikler seg m\u00e5 skrive test mot ingen kode. Nye utviklere m\u00e5 finne det vanskelig fordi de ville v\u00e6re forvirret om hva de skal teste uten \u00e5 ha koden for det. Men det er en vanlig ting, og med erfaring vil det bli jevnt. Den f\u00f8rste testen skrives uten \u00e5 skrive kode, og for \u00e5 deklarere klasse og metode, og testen vil ha en kompilasjonsfeil. Det neste trinnet vil v\u00e6re \u00e5 fikse kompileringsfeilen, og utf\u00f8re testen for \u00e5 mislykkes. Dette for\u00e5rsaker det r\u00f8de flagget.<\/p>\n\n

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

Etter den r\u00f8de fasen, ville det neste trinnet v\u00e6re \u00e5 skrive koden. Denne koden m\u00e5 best\u00e5 den f\u00f8rste testen. Bare \u00e5 skrive nok kode for \u00e5 sikre at bare den f\u00f8rste testen best\u00e5r, er en hindring mange utviklere st\u00e5r overfor i utgangspunktet. Fordi det i den neste testen m\u00e5tte mislykkes, etterfulgt av ny kode for \u00e5 passere dem. <\/p>\n\n

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

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

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

TDD passer godt inn i Agile -metodikken<\/strong><\/h3>\n\n

Det er ganske \u00e5penbart at prosjektkrav kan endres godt inn i utviklingsstadiet, s\u00e5 det \u00e5 ha TDD i samarbeid med Agile utvikling vil definitivt gj\u00f8re det vellykket og bygge prosjekter som er tilpasset kundens krav. Med testdrevet utvikling f\u00e5r du en tidligere tilbakemelding p\u00e5 prosjektet som du enkelt kan jobbe med. <\/p>\n\n

Det vil ogs\u00e5 bidra til \u00e5 forutse og kutte ned p\u00e5 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 \u00e5 bekymre seg for omfattende testskript. <\/p>\n\n

Konklusjon<\/strong><\/h3>\n\n

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

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

Testdrevet utvikling: hva det er, og hva det ikke er.<\/a><\/p>\n\n

Mer informasjon om testdrevet utvikling<\/a><\/p>\n\n

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

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

Forfatteren: Sascha Thattil jobber p\u00e5 Software-Developer-India.com som er en del av YUHIRO Group. YUHIRO er en tysk-indisk bedrift som tilbyr programmerere til IT-selskaper, byr\u00e5er og IT-avdelinger.<\/p>\n