Wat is Test Driven Development, oanpakken en foardielen

Test Driven Development (TDD) is in oanpak fan softwareûntwikkeling wêrby't testgefallen wurde ûntwikkele om oan te jaan en te falidearjen wat de koade sil dwaan.

Hast testgefallen foar elke funksje wurde makke en hifke foardat de software wurdt frijlitten, en as de test mislearret, wurdt nije koade skreaun (of opnij skreaun of patched) om de test troch te gean en de koade ienfâldich en bugfrij te meitsjen.

Test Driven Development (TDD) begjint mei it ûntwerpen en ûntwikkeljen fan tests foar elke lytse funksje yn in applikaasje. It TDD-ramt ynstruearret ûntwikkelders om nije koade allinich te skriuwen as in automatisearre test mislearre is. Dizze oanpak foarkomt koadeduplikaasje. De folsleine TDD-module is test-oandreaune ûntwikkeling.

Test Driven Development (TDD) is ûntstien as ûnderdiel fan in grutter software-ûntwerpparadigma bekend as Extreme Programming (XP), dy't diel útmakket fan 'e Agile-softwareûntwikkelingsmetoade.

It ienfâldige konsept fan TDD is om mislearre tests te skriuwen en te reparearjen foardat jo nije koade skriuwe (foar ûntwikkeling). Dit helpt koadeduplikaasje te foarkommen, om't wy in lyts oantal koade tagelyk skriuwe om tests troch te jaan. (Tests binne neat mear as easkbetingsten dy't wy moatte testen om se te foldwaan).

Test-oandreaune ûntwikkeling is in proses fan it ûntwikkeljen en útfieren fan automatisearre tests foardat de eigentlike ûntwikkeling fan 'e applikaasje. Dêrom wurdt TDD ek wol Test First Development neamd.

Fazen fan 'e TDD-oanpak

Foardat in nije koade wurdt skreaun, moat de programmeur earst in mislearre ienheidstest oanmeitsje. Dan makket de programmeur - as pear, as mob - krekt genôch koade om oan dy eask te foldwaan. Sadree't de test foarby is, kin de programmeur it projekt refaktorearje, ferbetteringen meitsje sûnder it gedrach te feroarjen.

Wylst TDD rjochtet him op ienheid-nivo programmeur ynteraksjes, der binne oare populêre metoaden, lykas akseptaasje test-driven ûntwikkeling (ATDD) of gedrach-oandreaune ûntwikkeling (BDD), dy't rjochtsje op tests dy't kin wurde begrepen troch klanten.

Dizze metoaden omfetsje it bouwen fan echte foarbylden as gearwurkjende tests tusken it yngenieurspersoniel en de klant foar kodearring, en dan de tests útfiere nei kodearring om te demonstrearjen dat de koade is ymplementearre. It hawwen fan de testen foarôf bekend ferbettert de kwaliteit fan de earste kear. ATDD en BDD fereaskje ûntwikkelders, testers en de saaklike kant om gear te wurkjen om de software en har gefolgen foar te stellen en te besprekken foardat de koade wurdt makke.

Foardielen fan TDD

Test-oandreaune ûntwikkeling kin tapassingen fan hege kwaliteit produsearje yn minder tiid dan mooglik is mei âldere metoaden. Súksesfolle ymplemintaasje fan TDD fereasket ûntwikkelders en testers om sekuer te antisipearjen hoe't de applikaasje en har funksjonaliteit sille wurde brûkt yn 'e echte wrâld.

TDD bout in regression-testsuite as in side-effekt dy't minsklike manuele testen kin minimalisearje, problemen earder fine, wat liedt ta rappere oplossingen. De metodyske aard fan TDD soarget foar folle hegere earste dekking en kwaliteit dan de klassike faze koade-syklusen> test> fix> retest. Om't testen betiid yn 'e ûntwerpsyklus wurdt útfierd, wurdt de tiid en jild bestege oan letter debuggen minimalisearre.

Ferwachte foardielen:

• signifikante ferlegings yn defekt tariven, op kosten fan in matige tanimming fan inisjele ûntwikkeling poging
• overheadkosten wurde mear as kompensearre troch in fermindering fan ynspanningen yn 'e lêste fazen fan projekten
• TDD liedt ta bettere ûntwerpkwaliteiten yn 'e koade en, mear algemien, in hegere graad fan "ynterne" of technyske kwaliteit, bygelyks troch it ferbetterjen fan de gearhing en koppelingsmetriken

Neidielen fan TDD

TDD fereasket in soad feardigens om suksesfol te wêzen, foaral op ienheidsnivo. In protte legacy-systemen binne gewoan net boud mei ienheidstesten yn gedachten, wêrtroch it ûnmooglik is om komponinten te isolearjen foar testen.

Ek misse in protte programmeurs de feardigens om skjinne koade te isolearjen en te meitsjen. Alle teamleden moatte ienheidstests oanmeitsje en ûnderhâlde, oars sille se gau ferâldere wurde. En in organisaasje dy't nei TDD sjocht, sil tiid moatte ynvestearje, no wat fertrage om letter hurder te gean.

Uteinlik, lykas by elke metoade, binne de definitive resultaten fan TDD allinich sa goed as de tests dy't waarden brûkt, hoe krekt se waarden útfierd, en de mjitte wêryn't se de betingsten mimike dy't brûkers fan it definitive produkt tsjinkomme.

Algemiene flaters:

• ferjit om faak testen út te fieren
• skriuw tefolle toetsen tagelyk
• skriuw tests dy't te grut of bruto binne
• it skriuwen fan te triviale tests, lykas it weilitten fan bewearingen
• skriuw tests foar triviale koade
• parsjele oannimmen: mar in pear ûntwikkelders yn in wurkgroep brûke TDD
• minne test suite ûnderhâld, meast liedt ta in test suite mei in ûnbidich lange run tiid
• testsuite ferlitten (d.w.s. komselden of nea rinne) - soms troch min ûnderhâld, soms troch teamomset

TDD filosofy

TDD lit de programmeur babystappen nimme by it skriuwen fan software. De test wurdt skreaun foar it testen fan de funksjonaliteit en soarget derfoar dat de applikaasje geskikt is foar testberens. Testen op in lyts oantal koade wurdt dien om flaters te fangen dy't foarkomme yn 'e hifke koade. Dan wurdt de funksjonaliteit ymplementearre. Dit wurdt oantsjut as in "reade griene refactor" dêr't read betsjut mislearjen en grien toant in pas. Dizze stappen wurde dan werhelle. It earste doel fan in programmeur is om te fokusjen op 'e taak by de hân en it te oerwinnen.

De ferskate stadia belutsen by in test-oandreaune ûntwikkelingssyklus binne:

• Foegje in test ta: Elke nije funksje yn TDD begjint mei in test dy't moat mislearje as it wurdt ynsteld foardat in funksje wurdt ymplementearre. De betingst foar it skriuwen fan in test foardat de funksje ymplementearret is in dúdlik begryp fan 'e eask troch de ûntwikkelder. Dit wurdt berikt troch brûkersferhalen en gebrûksgefallen. Dat in ûntwikkelder begrypt de eask foardat jo de programmakoade skriuwe.
• Run alle tests en kontrolearje oft de nije koade mislearret: dit soarget derfoar dat de test harnas wurket goed en dat de nije test net mislearret sûnder in nije koade. Dizze stap ferifiearret ek de test en elimineert de mooglikheid dat de nije test altyd sil trochjaan.
• Skriuw koade: De folgjende stap dy't folget is it skriuwen fan de koade dy't de test wisket. De nije koade is net perfekt, mar wurdt letter oanpast neffens de easken. It is gewoan ûntworpen foar testen en befettet gjin oare funksjes.
• Automatisearre tests útfiere: As elke produsearre testsaak de test maklik trochgiet, betsjut dit dat de koade foldocht oan alle fereaske spesifikaasjes. Dan kin de lêste faze fan 'e syklus begjinne.
• Refactoring koade: Dit is gelyk oan it fuortheljen fan duplikaasje. In refactoring brekt gjin besteande funksjonaliteit en helpt duplikaasje tusken produksje en testkoade te ferwiderjen. De koade is no skjinmakke as nedich.
• Werhelje: De syklus wurdt werhelle lykas yn 'e foarige gefallen mei in nije test. De essinsjele eask is dat de stap grutte is lyts, mei oer 1-10 feroarings tusken eltse test run. As de nije koade in nije test mislearret, moat de programmeur mear debuggen dwaan. Trochrinnende yntegraasje leveret omkearbere kontrôlepunten.

Ercole Palmeri