Kostir og gallar við prófdrifna þróun

Hvað eru kostir og gallar við prófdrifna þróun (TDD)?

Test Driven Development er hugbúnaðarþróunaraðferðafræði þar sem þú skrifar og hlaupa sett af prófum áður en þú skrifar kóða.

Hugmyndin er að þessi próf mistakist í fyrstu og þá byrjar þú að skrifa nægjanlegan kóða til að reyna að fá öll prófin til að standast. Að láta öll próf standast gæti verið mælikvarði á gert viðmið (dev-done) og eykur einnig traust á gæðum kóðans.


Sem sagt, eins og hver önnur þróunaraðferðafræði eru nokkrir kostir og gallar tengdir TDD. Hér töldum við upp nokkur þeirra, en áður, best að skýra nokkur atriði:

  • Að gera einingapróf þýðir ekki að gera TDD. Þú getur gert það fyrsta án þess að seinna. Reyndar er hægt að gera TDD án einingaprófana (en flestir gera það), í þessu tilfelli bætir fólk almennt við einingaprófanir með öðrum prófbragði. Það sem þú þarft örugglega er sjálfvirkar prófanir, hverjar sem þær eru.
  • Þú getur framkvæmt TDD til að prófa hvíta kassa til að prófa kóðann þinn. En þú getur líka framkvæmt TDD til að prófa svarta kassa, eitthvað sem oft er kallað atferlisstýrð þróun.

Hefð var fyrir því að kóða mikið af einingum og skrifa síðan einingapróf til að staðfesta kóðann. Þetta er fyrsti kóði, próf síðar aðferð. En ef enginn tími er gefinn eftir kóðunina eða þér er ýtt til losunar, þá er öllu æfingunni á einingaprófunum sleppt, eða í besta falli gert aftur í tímann.


Nú, á kostum og göllum TDD:





Kostir við prófdrifna þróun

  • Þar sem þú ert að skrifa lítil próf í einu neyðir það kóðann þinn til að vera mátari (annars væri erfitt að prófa það). TDD hjálpar þér að læra, skilja og innbyrða lykilreglur góðrar mátahönnunar.
  • TDD þvingar einnig fram góða arkitektúr. Til þess að gera kóðaeiningarprófanlega verður að vera rétt mátað. Með því að skrifa prófin fyrst hafa ýmis byggingarvandamál yfirborðið fyrr.
  • Skjalaðu kóðann þinn betur en skjöl (hann er ekki úreltur þar sem þú keyrir hann allan tímann).
  • Gerir kóða auðveldara að viðhalda og endurbæta. TDD hjálpar til við að veita skýrleika meðan á innleiðingarferlinu stendur og veitir öryggisnet þegar þú vilt endurskoða kóðann sem þú varst að skrifa.
  • Gerir samvinnu auðveldari og skilvirkari, liðsmenn geta breytt hver öðrum kóða af öryggi vegna þess að prófin munu upplýsa þau ef breytingarnar eru að láta kóðann hegða sér á óvæntan hátt.
  • Vegna þess að TDD neyðir þig í raun til að skrifa einingarpróf áður en þú skrifar útfærslukóða verður endurgerð kóða auðveldari og fljótlegri. Refactoring kóða skrifaður fyrir tveimur árum er erfitt . Ef þessi kóði er studdur af fjölda góðra einingaprófa er ferlið gert svo miklu auðveldara.
  • Hjálpar til við að koma í veg fyrir galla - ja, að minnsta kosti hjálpar það þér að finna vandamál varðandi hönnun eða kröfur strax í upphafi. TDD veitir snemma viðvörun við hönnunarvandamálum (þegar auðveldara er að laga þau).
  • Hjálpar forriturum að skilja kóðann sinn virkilega.
  • Býr til sjálfvirkan aðhvarfsprófunarpakka, í grundvallaratriðum ókeypis. þ.e.a.s. þú þarft ekki að eyða tíma á eftir í að skrifa einingapróf til að prófa framkvæmdarkóðann.
  • Það hvetur til lítilla skrefa og bætir hönnunina vegna þess að það fær þig til að klippa óþarfa ósjálfstæði til að auðvelda uppsetninguna.
  • Það hjálpar til við að skýra kröfur vegna þess að þú verður að komast að því nákvæmlega hvaða aðföng þú þarft að fæða og hvaða afköst þú búist við.
  • Einingarprófanir eru sérstaklega dýrmætar sem öryggisnet þegar breyta þarf kóðanum til að annað hvort bæta við nýjum eiginleikum eða laga núverandi villu. Þar sem viðhald er á bilinu 60 til 90% af líftíma hugbúnaðarins er erfitt að ofmeta hvernig tíminn sem tekinn er fram að því að búa til ágætis mengi einingaprófa getur borgað sig aftur og aftur yfir líftíma verkefnisins.
  • Prófun meðan þú skrifar neyðir þig líka til að reyna að gera viðmót þitt nógu hreint til að prófa. Það er stundum erfitt að sjá kostinn við þetta þangað til þú vinnur að meginmáli kóða þar sem það var ekki gert og eina leiðin til að æfa og einbeita þér að tilteknum kóða er að keyra allt kerfið og setja brotpunkt .
  • „Heimskuleg“ mistök nást nánast strax. Það hjálpar verktaki að finna mistök sem sóa tíma allra ef þau finnast í QA.


Gallar við prófdrifna þróun

  • Prófssettið sjálft verður að viðhalda; próf eru kannski ekki algjörlega afgerandi (þ.e. reiða sig á ytri ósjálfstæði).
  • Prófin geta verið erfið að skrifa, sérstaklega. umfram prófunarstig eininga.
  • Upphaflega hægir það á þróuninni; fyrir hratt endurtekningar gangsetningarumhverfi er framkvæmdakóðinn kannski ekki tilbúinn í nokkurn tíma vegna þess að eyða tíma í að skrifa próf fyrst. (En til lengri tíma litið flýtir það í raun fyrir þróun)
  • Eins og hver forritun er mikill munur á því að gera það og gera það vel. Að skrifa góð einingarpróf er listgrein. Þessi þáttur TDD er oft ekki ræddur, margir stjórnendur hafa tilhneigingu til að einbeita sér að mælikvarða eins og umfjöllun um kóða; þessar mælingar segja þér ekkert um gæði einingaprófanna.
  • Einingarprófun er eitthvað sem allt liðið þarf að kaupa í.
  • Áskorun til að læra. Það getur verið ógnvekjandi og ekki auðvelt fyrir neinn að læra í fyrstu, sérstaklega að reyna að læra það á eigin spýtur. Það krefst mikillar alúð (agi, æfing, þrautseigja) og þú verður að hafa það markmið að þú viljir stöðugt verða betri í því.
  • Erfitt að eiga við núverandi arfkóða.
  • Mikið af misskilningi sem heldur forriturum frá því að læra það.
  • Erfitt að byrja að vinna á þennan hátt. Sérstaklega ef þú hefur mörg ár í mörg önnur störf.
  • Þú verður stundum að hæðast að mörgum hlutum eða hlutum sem erfitt er að hæðast að. Það er til góðs til langs tíma, en sárt núna.
  • Þú verður að sinna þrifum stöðugt. Vegna þess að bókanir á fleiri og fleiri prófum gera uppbyggingu lengri og lengri er nauðsynlegt að betrumbæta prófin til að láta þau hlaupa hraðar eða fjarlægja óþarfa próf.
  • Eins og allir góðar aðferðir, má prófa einingapróf til hins ýtrasta. Stærsti ávinningurinn er af hóflegu átaki þar sem prófin eru alltaf notuð á kóðann á einfaldan hátt. Ef þú lendir í því að endurgera prófin þín oft, þá eru góðar líkur á að þú eyðir of miklum tíma í prófunarsettið.
  • Það getur verið auðvelt að láta trufla þig af „fluff“ eða fínum eiginleikum í einingaprófunum. Við ættum að muna að einföldustu prófin eru fljótlegust að búa til og auðveldast að stjórna þeim.
  • Þó að það sé bráðnauðsynlegt getur verið leiðinlegt að búa til próf fyrir bilanir en það borgar sig að lokum.
  • Refactoring snemma stigs krefst refactoring próf bekkja eins og heilbrigður.
  • Nema allir í teyminu haldi prófunum sínum rétt, getur allt kerfið hratt hrunið.