Fordele og ulemper ved testdrevet udvikling

Hvad er fordele og ulemper ved Test Driven Development (TDD)?

Test Driven Development er en softwareudviklingsmetode, hvor du skriver og løb et sæt tests, før du skriver kode.

Ideen er, at disse tests i første omgang mislykkes, og derefter begynder du at skrive nok kode til at prøve at få alle testene til at bestå. At have alle testene bestået kan være et mål for de udførte kriterier (dev-done) og øger også tilliden til kvaliteten af ​​koden.


Når det er sagt, er der ligesom alle andre udviklingsmetoder nogle fordele og ulemper forbundet med TDD. Her viser vi nogle af dem, men før det er bedst at afklare et par punkter:

  • At lave enhedstest betyder ikke, at du udfører TDD. Du kan gøre det første uden det andet. Faktisk kan du lave TDD uden enhedstest (men de fleste mennesker gør det), i dette tilfælde supplerer folk generelt enhedstest med andre smagsprøver. Hvad du helt sikkert har brug for er automatisk test, uanset hvad de er.
  • Du kan udføre TDD til test af hvide kasser for at teste din kode. Men du kan også udføre TDD til test af sort boks, noget der ofte kaldes Behavior Driven Development.

Traditionelt var processen at kode mange moduler og derefter skrive enhedstest for at bekræfte koden. Dette er kode-først, test senere metode. Men hvis der ikke er tid efter kodning, eller du bliver presset på for frigivelse, springes hele øvelsen af ​​enhedstest over eller i bedste fald tilbagevendende.


Nu videre til fordele og ulemper ved TDD:



Fordele ved testdrevet udvikling

  • Fordi du skriver små tests ad gangen, tvinger det din kode til at være mere modulær (ellers ville de være svære at teste mod). TDD hjælper dig med at lære, forstå og internalisere nøgleprincipperne for godt modulært design.
  • TDD styrker også god arkitektur. For at gøre din kode enhedstestbar, skal den moduleres ordentligt. Når man skriver testene, har forskellige arkitektoniske problemer tendens til at dukke op tidligere.
  • Dokumenterer din kode bedre end dokumentation (den går ikke forældet, da du kører den hele tiden).
  • Gør kode lettere at vedligeholde og refaktorere. TDD hjælper med at skabe klarhed under implementeringsprocessen og giver et sikkerhedsnet, når du vil omlægge den kode, du lige har skrevet.
  • Gør samarbejde nemmere og mere effektivt, teammedlemmer kan redigere hinandens kode med tillid, fordi testene informerer dem, hvis ændringerne får koden til at opføre sig på uventede måder.
  • Fordi TDD i det væsentlige tvinger dig til at skrive enhedstest, før du skriver implementeringskode, bliver refactoring af kode lettere og hurtigere. Refactoring kode skrevet for to år siden er hårdt . Hvis denne kode bakkes op af et sæt gode enhedstest, gøres processen så meget lettere.
  • Hjælper med at forhindre defekter - ja, i det mindste hjælper det dig med at finde design eller kravsproblemer lige i starten. TDD giver tidlig advarsel til designproblemer (når de er lettere at rette).
  • Hjælper programmører med at forstå deres kode.
  • Opretter en automatisk regressionstestsuite, dybest set gratis. dvs. du behøver ikke bruge tid bagefter på at skrive enhedstest for at teste implementeringskoden.
  • Det tilskynder til små trin og forbedrer designet, fordi det får dig til at klippe de unødvendige afhængigheder for at lette opsætningen.
  • Det hjælper med at afklare kravene, fordi du skal konkret finde ud af, hvilke input du skal føde, og hvilke output du forventer.
  • Enhedstest er især værdifulde som et sikkerhedsnet, når koden skal ændres for enten at tilføje nye funktioner eller rette en eksisterende fejl. Da vedligeholdelse tegner sig for mellem 60 og 90% af softwarelevecyklussen, er det svært at overvurdere, hvordan den tid, det tager foran at skabe et anstændigt sæt enhedstest, kan betale sig selv igen og igen i løbet af projektets levetid.
  • Test under skrivning tvinger dig også til at forsøge at gøre dine grænseflader rene nok til at blive testet. Det er undertiden svært at se fordelen ved dette, indtil du arbejder på en kode, hvor den ikke blev gjort, og den eneste måde at udøve og fokusere på et givet stykke kode er at køre hele systemet og indstille et brudpunkt .
  • 'Dumme' fejl fanges næsten med det samme. Det hjælper udviklere med at finde fejl, der spilder alles tid, hvis de blev fundet i QA.


Ulemper ved testdrevet udvikling

  • Selve testpakken skal vedligeholdes; test er muligvis ikke helt deterministiske (dvs. afhængige af eksterne afhængigheder).
  • Testene kan være svære at skrive, især ud over enhedstestniveauet.
  • Oprindeligt bremser udviklingen; til hurtigt iterative opstartsmiljøer er implementeringskoden muligvis ikke klar i nogen tid på grund af at bruge tid på at skrive test først. (Men i det lange løb fremskynder det faktisk udviklingen)
  • Som enhver programmering er der en stor forskel mellem at gøre det og gøre det godt. At skrive gode enhedstest er en kunstform. Dette aspekt af TDD diskuteres ofte ikke, mange ledere har tendens til at fokusere på målinger som kodedækning; disse målinger fortæller dig intet om kvalitet af enhedstestene.
  • Enhedstest er noget, som hele holdet skal købe ind.
  • En udfordring at lære. Det kan være skræmmende og ikke let for nogen at lære i starten, især når man prøver at lære det alene. Det kræver en masse dedikation (disciplin, praksis, vedholdenhed), og du skal have det mål, at du hele tiden vil blive bedre til det.
  • Svært at anvende på eksisterende ældre kode.
  • Mange misforståelser, der forhindrer programmører i at lære det.
  • Svært at begynde at arbejde på denne måde. Især hvis du har mange mange års arbejde på den anden vej.
  • Du er undertiden nødt til at spotte en masse ting eller ting, der er svære at spotte. Det er gavnligt på lang sigt, men smertefuldt lige nu.
  • Du skal udføre husholdning konstant. Da booking af flere og flere tests gør din opbygning længere og længere, er det nødvendigt at forfine disse tests for at få dem til at køre hurtigere eller fjerne overflødige tests.
  • Som enhver god teknik kan enhedstest føres til det ekstreme. De største fordele kommer fra en moderat indsats, idet testene altid udøver koden på den enkleste måde. Hvis du ofte finder ud af, at du omformulerer dine tests, er der en god chance for, at du bruger for meget tid på testpakken.
  • Det kan være let at blive distraheret af 'fnug' eller smarte funktioner i enhedstestningsrammen. Vi skal huske, at enkle tests er de hurtigste at skabe og de nemmeste at administrere.
  • Selv om det er absolut nødvendigt, kan det være kedeligt at oprette test for fejl, men det betaler sig meget i sidste ende.
  • Tidlig fase refactoring kræver også refactoring testklasser.
  • Medmindre alle på holdet korrekt vedligeholder deres test, kan hele systemet hurtigt nedbrydes.