Testa virzīta attīstība
Test Driven Development (TDD) ir programmatūras izstrādes pieeja, kurā testa gadījumi tiek izstrādāti, lai norādītu un apstiprinātu koda darbību. Vienkārši sakot, vispirms tiek izveidoti un pārbaudīti katras funkcionalitātes pārbaudes gadījumi, un, ja pārbaude neizdodas, tiek uzrakstīts jaunais kods, lai izturētu pārbaudi un padarītu kodu vienkāršu un bez kļūdām.
Testa virzīta izstrāde sākas ar testu izstrādi un izstrādi katrai mazai lietojumprogrammas funkcionalitātei. TDD uzdod izstrādātājiem rakstīt jaunu kodu tikai tad, ja nav izdevies automatizēts tests. Tas ļauj izvairīties no koda dublēšanās. Pilna TDD forma ir testa virzīta izstrāde.
Vienkārša TDD koncepcija ir neizrakstīto testu uzrakstīšana un labošana pirms jauna koda rakstīšanas (pirms izstrādes). Tas palīdz izvairīties no koda dublēšanās, jo mēs vienlaikus uzrakstām nelielu koda daudzumu, lai izturētu testus. (Pārbaudes nav nekas cits kā prasību nosacījumi, kas mums jāpārbauda, lai tos izpildītu).
Test-Driven izstrāde ir automatizētu testu izstrādes un palaišanas process pirms lietojumprogrammas faktiskās izstrādes. Tādējādi TDD dažreiz sauc arī par Test First Development.
Šajā apmācībā jūs uzzināsiet vairāk par
- Kā veikt TDD testu
- TDD vs. Tradicionālā testēšana
- Kas ir pieņemšanas TDD un izstrādātāja TDD
- TDD mērogošana, izmantojot Agile Model Driven Development (AMDD)
- Testa virzīta attīstība (TDD), salīdzinot ar Izveicīga modeļa virzīta attīstība (AMDD)
- TDD piemērs
- TDD priekšrocības
Kā veikt TDD testu
Šīs darbības nosaka, kā veikt TDD testu,
- Pievienojiet testu.
- Izpildiet visus testus un pārbaudiet, vai kāds jauns tests neizdodas.
- Uzrakstiet kodu.
- Palaidiet testus un Refactor kodu.
- Atkārtojiet.
TDD cikls nosaka
- Uzrakstiet testu
- Lieciet tai darboties.
- Mainiet kodu, lai tas būtu pareizs, ti, Refactor.
- Atkārtojiet procesu.
Daži paskaidrojumi par TDD:
- TDD nav ne par "testēšanu", ne par "dizainu".
- TDD nenozīmē "uzrakstīt dažus testus, pēc tam izveidot sistēmu, kas iztur testus.
- TDD nenozīmē "veikt daudz testu".
TDD vs. Tradicionālā testēšana
TDD pieeja galvenokārt ir specifikācijas paņēmiens. Tas nodrošina, ka jūsu pirmkods tiek rūpīgi pārbaudīts apstiprinošā līmenī.
- Veicot tradicionālo testēšanu, veiksmīgā pārbaudē tiek atrasts viens vai vairāki defekti. Tas ir tāds pats kā TDD. Kad pārbaude neizdodas, jūs esat guvis progresu, jo zināt, ka problēma ir jāatrisina.
- TDD nodrošina, ka jūsu sistēma faktiski atbilst tai noteiktajām prasībām. Tas palīdz palielināt jūsu uzticību savai sistēmai.
- TDD vairāk uzmanības tiek pievērsts ražošanas kodam, kas pārbauda, vai testēšana darbosies pareizi. Tradicionālajā testēšanā lielāka uzmanība tiek pievērsta testa gadījuma izstrādei. Vai pārbaude parādīs pareizu / nepareizu lietojumprogrammas izpildi, lai izpildītu prasības.
- TDD jūs sasniedzat 100% pārklājuma testu. Katra atsevišķa koda rinda tiek pārbaudīta atšķirībā no tradicionālās testēšanas.
- Gan tradicionālās testēšanas, gan TDD kombinācija noved pie tā, ka ir svarīgi pārbaudīt sistēmu, nevis pilnveidot sistēmu.
- Veiklā modelēšanā (AM) jums vajadzētu "pārbaudīt ar mērķi". Jums vajadzētu zināt, kāpēc jūs kaut ko testējat un kādā līmenī tas jāpārbauda.
Kas ir pieņemšanas TDD un izstrādātāja TDD
Ir divi TDD līmeņi
- Pieņemšanas TDD (ATDD): Ar ATDD jūs uzrakstāt vienu pieņemšanas testu. Šis tests atbilst specifikācijas prasībām vai sistēmas uzvedībai. Pēc tam uzrakstiet tikai tik daudz ražošanas / funkcionalitātes koda, lai izpildītu šo pieņemšanas testu. Pieņemšanas pārbaudē galvenā uzmanība tiek pievērsta sistēmas vispārējai uzvedībai. ATDD bija pazīstama arī kā uzvedības vadīta attīstība (BDD).
- Izstrādātāja TDD: Izmantojot Izstrādātāja TDD, jūs rakstāt vienu izstrādātāja testu, ti, vienības testu, un pēc tam tieši tik daudz ražošanas koda, lai izpildītu šo testu. Vienības pārbaude koncentrējas uz katru mazo sistēmas funkcionalitāti. Izstrādātāja TDD vienkārši sauc par TDD.
ATDD un TDD galvenais mērķis ir precīzi noteikt savam risinājumam detalizētas, izpildāmas prasības (JIT). JIT nozīmē ņemt vērā tikai tās prasības, kas nepieciešamas sistēmā. Tāpēc palieliniet efektivitāti.
TDD mērogošana, izmantojot Agile Model Driven Development (AMDD)
TDD ir ļoti labs detalizētā specifikācijā un validācijā. Tas neizdodas pārdomāt lielākus jautājumus, piemēram, vispārēju dizainu, sistēmas lietošanu vai lietotāja interfeisu. AMDD risina Agile mērogošanas problēmas, kuras TDD nav.
Tādējādi AMDD izmantoja lielākiem jautājumiem.
AMDD dzīves cikls.
Programmā Model-driven Development (MDD) pirms avota koda uzrakstīšanas tiek izveidoti plaši modeļi. Kuriem savukārt ir veiklā pieeja?
Iepriekš redzamajā attēlā katrs lodziņš attēlo attīstības darbību.
Paredzēšana ir viens no TDD testu prognozēšanas / iztēlošanās procesiem, kas tiks veikts projekta pirmajā nedēļā. Paredzēšanas galvenais mērķis ir identificēt sistēmas darbības jomu un sistēmas arhitektūru. Lai veiksmīgi iedomātos, tiek veiktas augsta līmeņa prasības un arhitektūras modelēšana.
Tas ir process, kurā netiek veikta detalizēta programmatūras / sistēmas specifikācija, bet programmatūras / sistēmas prasību izpēte nosaka projekta vispārējo stratēģiju.
- 0 atkārtojums: Paredzēšana
Ir divi galvenie apakšaktivizatori.
- Sākotnējo prasību paredzēšana.
Lai noteiktu augsta līmeņa prasības un sistēmas darbības jomu, var paiet vairākas dienas. Galvenā uzmanība tiek pievērsta lietošanas modeļa, sākotnējā domēna modeļa un lietotāja saskarnes modeļa (UI) izpētei.
- Sākotnējā arhitektūras plānošana.
Sistēmas arhitektūras identificēšana prasa arī vairākas dienas. Tas ļauj noteikt projekta tehniskos virzienus. Galvenais mērķis ir izpētīt tehnoloģiju diagrammas, lietotāja saskarnes (UI) plūsmu, domēnu modeļus un izmaiņu gadījumus.
- Iterāciju modelēšana:
Šeit komandai jāplāno darbs, kas tiks veikts katrā atkārtojumā.
- Katrā atkārtojumā tiek izmantots veikls process, ti, katra atkārtojuma laikā prioritāri tiks pievienots jauns darba vienums.
- Tiks ņemts vērā pirmais darbs ar augstāku prioritāti. Pievienotos darba priekšmetus var priorizēt vai noņemt no priekšmetu kaudzes jebkurā laikā.
- Komanda apspriež, kā viņi īstenos katru prasību. Šim nolūkam tiek izmantota modelēšana.
- Modelēšanas analīze un dizains tiek veikts katrai prasībai, kas tiks ieviesta attiecīgajā atkārtojumā.
- Modes vētra:
To sauc arī par modelēšanu tieši laikā.
- Šajā modelēšanas sesijā piedalās 2/3 dalībnieku komanda, kas apspriež jautājumus uz papīra vai tāfeles.
- Viens komandas loceklis lūgs citu modelēt kopā ar viņu. Šī modelēšanas sesija ilgs apmēram 5 līdz 10 minūtes. Kur komandas dalībnieki pulcējas kopā, lai dalītos ar tāfeli / papīru.
- Viņi pēta jautājumus, kamēr neatrod galveno problēmas cēloni. Tieši laikā, ja viens komandas loceklis identificē problēmu, kuru viņš / viņa vēlas atrisināt, viņš / viņa ātri izmantos citus komandas locekļus.
- Pēc tam citi grupas dalībnieki izpēta šo jautājumu, un visi turpina darboties tāpat kā iepriekš. To sauc arī par stand-up modelēšanu vai klientu QA sesijām.
- Testa virzīta attīstība (TDD).
- Tas veicina jūsu pieteikuma koda un detalizētas specifikācijas apstiprinošu pārbaudi.
- Gan pieņemšanas tests (detalizētas prasības), gan izstrādātāja testi (vienības tests) ir TDD izejviela.
- TDD padara kodu vienkāršāku un skaidrāku. Tas ļauj izstrādātājam saglabāt mazāk dokumentācijas.
- Atsauksmes.
- Tas nav obligāts. Tas ietver koda pārbaudes un modeļu pārskatus.
- To var izdarīt katram atkārtojumam vai visam projektam.
- Šī ir laba iespēja sniegt atsauksmes par projektu.
Testa virzīta attīstība (TDD), salīdzinot ar Izveicīga modeļa virzīta attīstība (AMDD)
| TDD | AMDD |
|
|
|
|
|
|
|
|
|
|
|
|
| -------------------------------------------- |
TDD piemērs
Šajā piemērā mēs definēsim klases paroli. Šajā klasē mēs centīsimies izpildīt šādus nosacījumus.
Paroles pieņemšanas nosacījums:
- Parolei jābūt no 5 līdz 10 rakstzīmēm.
Pirmkārt, mēs uzrakstām kodu, kas atbilst visām iepriekšminētajām prasībām.
1. scenārijs : lai palaistu testu, mēs izveidojam klasi PasswordValidator ();
Mēs darbosimies virs klases TestPassword ();
Izeja tiek izieta, kā parādīts zemāk;
Izeja :
2. scenārijs : Šeit mēs varam redzēt metodi TestPasswordLength (), nav nepieciešams izveidot klases PasswordValidator instanci. Piemērs nozīmē klases objekta izveidošanu, lai atsauktos uz šīs klases dalībniekiem (mainīgajiem / metodēm).
Mēs no koda noņemsim klasi PasswordValidator pv = new PasswordValidator (). IsValid () metodi mēs varam izsaukt tieši ar PasswordValidator. IsValid ("Abc123") . (Skatīt attēlu zemāk)
Tātad mēs Refactor (mainīt kodu), kā norādīts zemāk:
3. scenārijs : Pēc izejas atjaunošanas parādīts neizdevies statuss (skatiet attēlu zemāk), tāpēc, ka mēs esam noņēmuši gadījumu. Tāpēc nav atsauces uz nestatisku metodi isValid ().
Tāpēc mums ir jāmaina šī metode, pievienojot vārdu "static" pirms Būla, jo publiskā statiskā būla vērtība irValid (virknes parole). Refactoring Class PasswordValidator (), lai novērstu iepriekšējo kļūdu, lai nokārtotu testu.
Izeja:
Pēc izmaiņu veikšanas PassValidator () klasē, ja mēs veiksim testu, izeja tiks izieta, kā parādīts zemāk.
TDD priekšrocības
- Priekšlaicīgs kļūdu paziņojums.
Izstrādātāji pārbauda savu kodu, taču datu bāzes pasaulē tas bieži sastāv no manuāliem testiem vai vienreizējiem skriptiem. Izmantojot TDD, laika gaitā tiek izveidots automatizētu testu komplekts, kuru jūs un jebkurš cits izstrādātājs varat atkārtot pēc vēlēšanās.
- Labāk izstrādāts, tīrāks un paplašināmāks kods.
- Tas palīdz saprast, kā kods tiks izmantots un kā tas mijiedarbojas ar citiem moduļiem.
- Tā rezultātā tiek pieņemts labāks dizains un uzturamāks kods.
- TDD ļauj rakstīt mazāku kodu ar vienu atbildību, nevis monolītās procedūras ar vairākiem pienākumiem. Tas padara kodu vienkāršāku saprotamu.
- TDD arī liek rakstīt tikai ražošanas kodu, lai nokārtotu testus, pamatojoties uz lietotāja prasībām.
- Uzticība refaktoram
- Ja jūs pārveidojat kodu, kodā var būt pārtraukumu iespējas. Tātad, izmantojot automātisko testu komplektu, jūs varat izlabot šos pārtraukumus pirms izlaišanas. Pareizs brīdinājums tiks sniegts, ja, izmantojot automātiskos testus, tiks konstatēti pārtraukumi.
- Izmantojot TDD, vajadzētu iegūt ātrāku, paplašināmu kodu ar mazāk kļūdām, kuras var atjaunināt ar minimālu risku.
- Labi komandas darbam
Ja nav neviena komandas locekļa, citi komandas locekļi var viegli uzņemt kodu un strādāt pie tā. Tas arī palīdz dalīties zināšanās, tādējādi padarot komandu kopumā efektīvāku.
- Labi izstrādātājiem
Lai gan izstrādātājiem ir jāpavada vairāk laika, rakstot TDD testa gadījumus, atkļūdošanai un jaunu funkciju izstrādei nepieciešams daudz mazāk laika. Jūs rakstīsit tīrāku, mazāk sarežģītu kodu.
Kopsavilkums:
- TDD apzīmē testa virzītu attīstību. Tas ir koda modificēšanas process, lai izturētu iepriekš izstrādātu testu.
- Tas vairāk uzsver ražošanas kodu, nevis testa gadījuma dizainu.
- Testa virzīta izstrāde ir koda modificēšanas process, lai izturētu iepriekš izstrādātu testu.
- Programmatūras inženierijā to dažkārt sauc par "Test First Development".
- TDD ietver koda atjaunošanu, ti, mainot / pievienojot noteiktu koda daudzumu esošajam kodam, neietekmējot koda darbību.
- TDD, to lietojot, kods kļūst skaidrāks un saprotamāks.
Šī raksta autors ir Kanchan Kulkarni