Hva Er Testdrevet Utvikling (Tdd)?

large__8282043567 Testdrevet Utvikling er en prosess som er avhengig av gjentakelse av svært kort utviklingssyklus. Den er basert på test-første konseptet Extreme Programming (XP) som oppfordrer enkel design med høy grad av tillit.

prosedyren for å gjøre TDD følger:

  1. Skriv en test
  2. Kjør alle tester
  3. Skriv implementeringskoden
  4. Kjør Alle tester
  5. Refactor

denne prosedyren kalles Ofte Rød-Grønn-Refactor.

mens du skriver tester, er vi i rød tilstand. Siden testen er skrevet før den faktiske implementeringen, skal den mislykkes. Hvis ikke, er testen feil. Det beskriver noe som allerede eksisterer, eller det ble skrevet feil. Å være i grønt mens du skriver tester er et tegn på falsk positiv. Tester som det bør fjernes eller refactored.

Neste kommer den grønne tilstanden. Når implementeringen av den siste testen er ferdig, bør alle tester passere. Hvis de ikke gjør det, er implementeringen feil og bør korrigeres.

tanken er ikke å gjøre implementeringen endelig, men å gi akkurat nok kode for tester å passere. Når alt er grønt, kan vi fortsette å refactor den eksisterende koden. Det betyr at vi gjør koden mer optimal uten å innføre nye funksjoner. Mens refactoring er på plass, bør alle tester passere hele tiden. Hvis en av dem mislykkes, brøt refactor en eksisterende funksjonalitet. Refactoring bør ikke inkludere nye tester.

Hastighet er nøkkelen

large_5836417589
JEG pleier Å se TDD som et spill av ping pong (eller bordtennis). Spillet er veldig fort. Det samme gjelder FOR TDD. Jeg pleier ikke å bruke mer enn et minutt på hver side av bordet(test og implementering). Skriv en kort test og kjør den (ping), skriv implementeringen og kjør alle tester (pong), skriv en annen test (ping), skriv implementering av den testen (pong), refactor og bekreft at alle tester passerer (score), gjenta. Ping, pong, ping, pong, ping, pong, score, tjene igjen. Ikke prøv å lage den perfekte koden. I stedet, prøv å holde ballen rullende til du tror at tiden er riktig å score (refactor).

det handler ikke om testing

T I TDD blir ofte misforstått. TDD er måten vi nærmer design. Det er måten å tvinge oss til å tenke på implementeringen før du skriver koden. Det er måten å bedre strukturere koden. Det betyr ikke at tester som følge av BRUK AV TDD er ubrukelige. Langt fra det. De er veldig nyttige og tillater oss å utvikle seg med stor fart uten å være redd for at noe vil bli ødelagt. Det gjelder spesielt når refactoring finner sted. Å kunne omorganisere koden mens du har tillit til at ingen funksjonalitet er ødelagt, er et stort løft for kvaliteten på koden.

hovedmålet MED TDD er kodedesign med tester som et svært nyttig sideprodukt.

Tentamen

for at tester skal kjøre fort og dermed gi konstant tilbakemelding, kode må organiseres på en måte som metoder, funksjoner og klasser kan lett spottet og stubbed. Hastigheten på utførelsen vil bli sterkt påvirket det, for eksempel våre tester må kommunisere med databasen. Ved å spotte eksterne avhengigheter kan vi øke den hastigheten drastisk. Hele enheten tester suite utførelse bør måles i minutter hvis ikke sekunder. Enda viktigere enn fart, utforme koden på en måte at det lett kan spotte og stubbed tvinger oss til å bedre strukturere koden ved å bruke separasjon av bekymringer. Med eller uten mocks skal koden skrives på en måte at vi for eksempel enkelt kan erstatte en database for en annen. At «en annen» kan være, for eksempel, spottet eller in-memory database.

et eksempel På tentamen I Scala Finnes I Scala Test-Driven Development (TDD): Unit Testing File Operations med Specs2 og mockito artikkel. Hvis ditt valgte programmeringsspråk Ikke Er Scala, kan artikkelen fortsatt være svært nyttig for å se mønsteret som kan brukes på alle språk.

Overvåkere

Svært nyttig verktøy når du arbeider I TDD mote er overvåkere. De er rammer eller verktøy som utføres før vi begynner å jobbe og ser etter endringer i koden. Når en slik endring oppdages, kjøres alle testene. I Tilfelle JavaScript tillater nesten alle byggesystemer og oppgaveløpere dette. Gulp (min favoritt) og Grunt er to av mange eksempler. Scala har sbt-revolver (blant andre). De fleste andre programmeringsspråk har lignende verktøy som rekompilerer (om nødvendig) og kjører alle (eller berørte) tester når koden endres. Jeg ender alltid med å ha skjermen delt inn i to vinduer. En med koden jeg jobber med og den andre med resultater av tester som blir utført kontinuerlig. Alt jeg trenger å gjøre er å være oppmerksom på at utgangen av disse seerne tilsvarer fasen jeg er i (rød eller grønn).

Dokumentasjon

en annen svært nyttig bivirkning AV TDD (og velstrukturerte tester generelt) er dokumentasjon. I de fleste tilfeller er det mye lettere å finne ut hva koden gjør ved å se på tester enn selve implementeringen. Ekstra fordel at andre typer dokumentasjon ikke kan gi er at testene er aldri utdatert. Hvis det er uoverensstemmelse mellom tester og implementeringskoden, mislykkes testene. Mislykkede tester betyr unøyaktig dokumentasjon.

Tester Som dokumentasjonsartikkel gir en litt dypere begrunnelse bak bruken av tester i stedet for tradisjonell dokumentasjon.

Sammendrag

I min erfaring ER TDD trolig det viktigste verktøyet vi har i vår programvare verktøykasse. Det tar mye tid og tålmodighet å bli dyktig I TDD, men når den kunsten er mestret, øker produktiviteten og kvaliteten drastisk. Den beste måten å både lære OG praktisere TDD er i kombinasjon med parprogrammering. Som i et spill av ping pong som krever to deltakere, KAN TDD være i par hvor en koder skriver tester og den andre skriver gjennomføringen av disse testene. Roller kan bytte etter hver test (som det ofte gjøres i kodende dojoer).

Gi det en sjanse og ikke gi opp når møtt med hindringer siden det vil være mange.

Testdrevet Utvikling (Tdd): Beste Praksis Ved Bruk Av Java-Eksempler er et godt utgangspunkt. Selv om Den bruker Java eksempler, samme, om ikke alle, praksis kan brukes til alle programmeringsspråk. For et eksempel I Java (som i forrige tilfelle, er det lett aplicable til andre språk) ta en titt PÅ Tdd Eksempel Walkthrough artikkel.

En annen flott måte å perfeksjonere tdd ferdigheter er kode katas (det er mange på dette nettstedet).

Hva er din erfaring med TDD? Det er så mange variasjoner som det er lag som praktiserer det, og jeg vil gjerne høre om din erfaring.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert.