Voor- en nadele van toetsgedrewe ontwikkeling

Wat is die voor- en nadele van toetsgedrewe ontwikkeling (TDD)?

Toetsgedrewe ontwikkeling is 'n sagteware-ontwikkelingsmetodiek waardeur u skryf en hardloop 'n stel toetse voordat u kode skryf.

Die idee is dat die toetse eers sal misluk en dan begin u genoeg kode skryf om al die toetse te laat slaag. As u al die toetse slaag, kan dit 'n maatstaf wees van die kriteria wat u gedoen het (dev-done) en verhoog dit ook die vertroue in die kwaliteit van die kode.


Dit gesê, soos enige ander ontwikkelingsmetodologieë, is daar 'n paar voor- en nadele verbonde aan TDD. Hier noem ons 'n paar daarvan, maar dit is die beste om 'n paar punte te verduidelik:

  • Om eenheidstoetse te doen, beteken nie dat u TDD doen nie. U kan die eerste doen sonder die tweede. In werklikheid kan u TDD doen sonder eenheidstoetse (maar die meeste mense doen dit). In hierdie geval vul mense gewoonlik die eenheidstoets aan met ander soorte toetse. Wat u beslis nodig het, is outomatiese toetsing, ongeag wat hulle is.
  • U kan TDD uitvoer vir witboks toets om u kode te toets. Maar u kan ook TDD uitvoer vir die toets van swart bokse, iets wat dikwels gedragsgedrewe ontwikkeling genoem word.

Tradisioneel was die proses om baie modules te kodeer en dan eenheidstoetse te skryf om die kode te verifieer. Dit is kode-eerste, toets later metode. Maar as u nie na die kodering tyd het nie, of u dit vir vrylating beywer, word die hele oefening van eenheidstoetse oorgeslaan, of ten beste terugwerkend gedoen.


Nou, oor die voor- en nadele van TDD:



Voordele van toetsgedrewe ontwikkeling

  • Omdat u klein toetse tegelyk skryf, dwing dit u kode om meer modulêr te wees (anders sou dit moeilik wees om te toets). TDD help u om die sleutelbeginsels van goeie modulêre ontwerp te leer, te verstaan ​​en te internaliseer.
  • TDD dwing ook goeie argitektuur. Om u kode eenheidstoetsbaar te maak, moet dit behoorlik gemodulariseer word. As u eers die toetse skryf, kom verskillende argitektoniese probleme vroeër na vore.
  • Dokumenteer u kode beter as dokumentasie (dit is nie verouderd nie, want u gebruik dit heeltyd).
  • Maak kode makliker om in stand te hou en te refakteer. TDD help om duidelikheid te gee tydens die implementeringsproses en bied 'n veiligheidsnet wanneer u die kode wat u pas geskryf het, wil herlei.
  • Maak samewerking makliker en doeltreffender; spanlede kan mekaar se kode met selfvertroue wysig, want die toetse sal hulle inlig as die veranderinge die kode op onverwagte maniere laat optree.
  • Omdat TDD u in wese dwing om eenheidstoetse te skryf voordat u implementeringskode skryf, word die heraktivering van kode makliker en vinniger. Refactoring-kode wat twee jaar gelede geskryf is, is moeilik . As die kode deur 'n aantal goeie eenheidstoetse gerugsteun word, word die proses soveel makliker gemaak.
  • Help help om gebreke te voorkom - wel, dit help u ten minste aan die begin van die ontwerp- of vereistevraagstukke. TDD bied vroeë waarskuwings aan ontwerpprobleme (wanneer dit makliker is om op te los).
  • Help programmeerders om hul kode regtig te verstaan.
  • Skep 'n outomatiese regressietoetspakket, basies gratis. dit wil sê jy hoef nie daarna tyd te spandeer om eenheidstoetse te skryf om die implementeringskode te toets nie.
  • Dit moedig klein treë aan en verbeter die ontwerp, want dit laat u die onnodige afhanklikhede sny om die opstel te vergemaklik.
  • Dit help om die vereistes duideliker te maak, want u moet konkreet agterkom watter insette u moet voer en watter uitsette u verwag.
  • Eenheidstoetse is veral waardevol as 'n veiligheidsnet wanneer die kode verander moet word om nuwe funksies by te voeg of 'n bestaande fout reg te stel. Aangesien onderhoud tussen 60 en 90% van die lewensiklus van die sagteware uitmaak, is dit moeilik om te oordeel hoe die tyd wat vooraf geneem is om 'n ordentlike stel eenheidstoetse te skep, oor die hele leeftyd van die projek homself kan betaal.
  • Toetsing tydens skryfwerk dwing u ook om u koppelvlakke skoon genoeg te maak om getoets te word. Dit is soms moeilik om die voordeel hiervan te sien totdat u aan 'n kode kode werk waar dit nie gedoen is nie, en die enigste manier om op 'n gegewe stuk kode te oefen en te konsentreer, is om die hele stelsel te laat loop en 'n breekpunt in te stel. .
  • 'Dom' foute word amper dadelik vasgevang. Dit help ontwikkelaars om foute te vind wat almal se tyd sou mors as hulle in QA gevind word.


Nadele van toetsgedrewe ontwikkeling

  • Die toetsstel self moet onderhou word; toetse is dalk nie heeltemal deterministies nie (dit wil sê afhanklik van eksterne afhanklikhede).
  • Die toetse kan moeilik wees om te skryf, veral buite die eenheidstoetsvlak.
  • Aanvanklik vertraag dit die ontwikkeling; vir vinnig iteratiewe opstartomgewings is die implementeringskode moontlik 'n geruime tyd nie gereed nie, omdat u eers tyd daaraan bestee om toetse te skryf. (Maar op die lange duur bespoedig dit die ontwikkeling eintlik)
  • Soos enige programmering is daar 'n groot verskil tussen dit doen en goed doen. Die skryf van goeie eenheidstoetse is 'n kunsvorm. Hierdie aspek van TDD word dikwels nie bespreek nie, baie bestuurders is geneig om te fokus op maatstawwe soos kodedekking; daardie statistieke vertel u niks van die gehalte van die eenheidstoetse.
  • Eenheidstoetse is iets waarvoor die hele span moet koop.
  • 'N Uitdaging om te leer. Dit kan aanvanklik intimiderend wees en vir niemand maklik om te leer nie, veral om dit self te leer. Dit vereis baie toewyding (dissipline, oefening, volharding) en u moet die doel hê dat u voortdurend wil verbeter.
  • Moeilik om toe te pas op bestaande nalatenskapkode.
  • Baie wanopvattings wat programmeerders weerhou om dit te leer.
  • Moeilik om op hierdie manier te begin werk. Veral as u baie jare anders werk.
  • U moet soms met baie dinge of dinge bespot wat moeilik is om te bespot. Dit is voordelig op lang termyn, maar tans pynlik.
  • U moet voortdurend huishoud. Omdat u al hoe meer toetse bespreek, is dit nodig om die toetse te verfyn om vinniger te laat werk of om oortollige toetse te verwyder.
  • Soos enige goeie tegniek, kan eenheidstoetse tot die uiterste gevoer word. Die grootste voordele is 'n matige poging, met die toetse om die kode altyd op die eenvoudigste manier moontlik uit te oefen. As u gereeld u toetse heraktiveer, is die kans groot dat u te veel tyd aan die toetsstel spandeer.
  • Dit kan maklik wees om afgelei te word deur 'pluis' of fiksheid in die eenheidstoetsraamwerk. Ons moet onthou dat eenvoudige toetse die vinnigste is om te skep en die maklikste om te bestuur.
  • Alhoewel dit absoluut noodsaaklik is, kan die vervaardiging van toetse vir mislukkings vervelig wees, maar uiteindelik betaal dit baie tyd.
  • Vroegtydige heraktivering vereis ook heraktivering van toetsklasse.
  • Tensy almal in die span hul toetse korrek onderhou, kan die hele stelsel vinnig agteruitgaan.