Kodėl bandomasis vystymas (TDD) yra geriausias patikimo kodavimo būdas.

Pirmiausia parašykite vienetų testus, tada parašykite kodą.

Vaizdo kreditai: Pexels.com

Prieš keletą metų, kai pirmą kartą išgirdau apie „Test Driven Development“, buvau skeptiškas.

Pati idėja „pirmiausia parašyti vienetų testus, tada parašyti kodą“ man buvo niūri.

Kodėl to nebūtų? Pirmiausia parašykite savo vienetų testus? Kas darytų šmaikštų dalyką?

Bet aš tada buvau profesionalus programuotojas 10 metų ir mačiau, kad viskas vyksta ir vyksta pramonėje. Aš žinojau geriau, nei atmesti bet ką iš rankų, ypač kai kūrėjai buvo taip įžvalgūs.

Taigi pasitariau su drauge, kuri parodė pagrindinį pavyzdį.

Šis pagrindinis pavyzdys turi LCL_SUM klasę su SUM metodu. Šis metodas yra atsakingas už skaičių pridėjimą. Jis imasi skaičiaus kaip importuojančio parametro ir tada prideda jį prie savęs, kad gautų rezultatą. Pavadinkime šį metodą kaip gamybos metodą.

Klasės kodas buvo toks:

KLASĖ lcl_sum APIBRĖŽIMAS.
VIEŠASIS SKIRSNIS.
METODAI: SUMOS IMPORTO iv_1 TIPAS i
GRĄŽINANTI VERTĖ (rv_sum) TIPAS i.
ENDCLASS. „Lcl_sum“ APIBRĖŽIMAS
*
PASIRINKIMO PRADŽIA.
* Dar nieko čia
*
*
KLASĖS lcl_sum ĮGYVENDINIMAS.
METODO SUMA.
rv_sum = iv_1 * iv_1. „Tyčinė klaida (padauginau, o ne pridedu)
ENDMETHOD. "suma
ENDCLASS. „Lcl_sum“ ĮGYVENDINIMAS.

Testo klasės nustatymas

Dabar sukurkite klasę, kuri veiktų kaip bandomoji klasė. SAP apibrėždami klasę, turėsite pridėti raktinį žodį TESTAVIMAS. Šis papildymas atskiria šią klasę nuo gamybos kodo.

KLASĖS lcl_test BANDYMŲ APIBRĖŽIMAS
VIEŠASIS SKIRSNIS.
METODAI: M_sum TYRIMUI.
ENDCLASS. „Lcl_test APIBRĖŽIMAS
*
KLASĖS „lcl_test“ ĮGYVENDINIMAS.
METODAS m_sum.
ENDMETHOD. „M_sum“
ENDCLASS. „Lcl_test“ ĮGYVENDINIMAS

Testo metodo įgyvendinimas

Taikant šį bandymo metodą reikia atlikti šiuos veiksmus: - Išbandykite gamybos kodą. Taigi, norint išbandyti LCL_SUM metodo SUM, jums reikės akimirksniu objekto nuorodą į LCL_SUM, paskambinkite metodu SUM, siunčiantį manekeno vertę.

Remiantis manekeno reikšme, metodas jums atsiųstų rezultatą - tikrąjį metodo rezultatą. Remdamiesi manekeno verte, jūs žinote, kokia būtų tikėtina vertė. E. g. Jei SUM metodui priskirsite skaičių 3, gausite 6 rezultatą, nes jis pridedamas prie 3.

Gavę tikrąjį rezultatą iš bandomo gamybos kodo ar metodo, turite palyginti rezultatus. Jei tikrasis ir laukiamasis neatitinka, turite pranešti sistemai, kad kažkas negerai su faktiniu ir tikėtinuoju, ir parodyti tinkamą pranešimą.

KLASĖS „lcl_test“ ĮGYVENDINIMAS.
METODAS m_sum.
DUOMENYS: o_cut TIPO ATASKAITA Į lcl_sum.
DUOMENYS: lv_result TYPE i.
*
CREATE OBJECT o_cut.
lv_result = o_cut-> suma (3).
*
cl_aunit_assert => assert_equals (
Tinka iki = 6
aktas = lv_rezultatas
msg = 'kažkas negerai išvestyje'
).
ENDMETHOD. „M_sum“
ENDCLASS. „Lcl_test“ ĮGYVENDINIMAS

Vieneto testo rezultatai

Tai man sako, kad įgyvendinant gamybos metodą yra kažkas ne taip.

Taip, jei atidžiai pažvelgsite į SUM metodo įgyvendinimą, aš turiu rašybos klaidą, o ne apibendrinimą, buvau panaudojęs daugybą. Taigi, aš jį pataisyčiau ir pakartotinai paleisčiau testą, kad jis būtų sėkmingai įvykdytas.

Buvau užsikabinęs prie TDD. Flabbergasted būtų teisingas žodis.

Stebina buvo labai sutrumpėjęs kūrimo ir bandymo ciklo laikas.

Aš buvau įpratęs rašyti kodą didesnę valandos dalį prieš bandydamas jį sudaryti ar paleisti. Bet čia kodas buvo vykdomas ir tikrinamas maždaug kas 2 minutes.

Taigi, trumpai tariant, TDD realizuojamas per trumpus kūrimo ciklus, kurių metu laikomasi taisyklės „pirmiausia užrašykite vieneto testus, tada parašykite kodą, tada sukurkite reaktorių, tada pakartokite“. Vieneto testai yra automatiniai testai, kurie patikrina, ar funkcijos veikia taip, kaip tikėtasi. Pirmasis jūsų vieneto testas turėtų būti nesėkmingas, nes jis parašytas prieš jums net neturint kodo bazės.

Šiek tiek pridedate bandomosios bylos kodą. Šiek tiek pridedate gamybos kodą. Abu kodo srautai vienu metu išauga į papildomus komponentus. Testai atitinka gamybos kodą, kaip antikūnas tinka antigenui.

Ši priemonė neleidžia kūrėjams parašyti nereikalingo kodo, kuris neatitinka nurodyto testo.

Ir šis visas integruotas požiūris suteikia daug naudos kūrėjui.

Jūs ištaisote blogą kodą, nieko nepažeisdami.

Kai matote neteisingą kodą, užmerkite akis, meldžiatės Dievui ir ištariate vieną iš dviejų teiginių.

· „Tai yra netvarka. Manau, kad turiu kažkaip tai sutvarkyti “.

· „Aš to neliečiu“.

Bet kuriuo atveju yra tam tikras baimės elementas. Tiesą sakant, netikrumas.

Ką daryti, jei mano kodas suardo esamą funkciją?

TDD padeda tiksliai įveikti tą netikrumą.

Svarbu pabrėžti, kad TDD aplinkoje kūrėjai sutelkia dėmesį į bandymų vykdymą, kad būtų išvengta klaidų, o ne pašalintos po to, kai kodas bus parašytas. Tai yra vienas galingiausių TDD pranašumų. Kai turite patikimų testų rinkinį, prarasite visišką baimę atlikti pakeitimus. Pamatę netinkamą kodą, jūs tiesiog jį išvalote vietoje.

Kuo tvarkingesnis jūsų kodas, tuo mažiau komandos pastangų reikia įdėti į naujas funkcijas ar modifikuoti esamą kodo bazę.

TDD vykdo dokumentaciją.

Dikas Brandonas smogė jam į nagą, kai pastebėjo.

„Dokumentacija yra kaip seksas; kai gerai, tai labai, labai gerai, o kai blogai, tai geriau nei nieko “.

Dokumentacija yra programavimo ricinos aliejus. Vadybininkai mano, kad gerai programuotojams, o programuotojai to nekenčia!

viena įprasta priežastis, kodėl atsiranda apimties šliaužimas, yra dokumentų, turinčių aiškiai apibrėžtus reikalavimus, trūkumas. Šią problemą galima sušvelninti plėtojant bandymus.

TDD aplinkoje kūrėjai rašo vienetinius testus tam tikriems kodo segmentams išbandyti. Vieneto testai naudojami kaip specifikacijos, apibūdinančios tikslias ypatybes, kurios turėtų būti įdiegtos. Todėl tiksliai nurodyti testai neleidžia kūrėjams parašyti nereikalingo kodo.

Ir šie vienetų testai yra dokumentai. Jie apibūdina žemiausio lygio sistemos dizainą. Jie yra nedviprasmiški, tikslūs, parašyti auditorijai suprantama kalba ir yra tokie oficialūs, kad juos vykdo. Tai yra geriausia žemo lygio dokumentacija, kuri gali būti.

TDD padeda kurti geriau

Pagrindinė TDD sąlyga yra tai, kad prieš rašydami kodą turite parašyti savo vieneto bandymo atvejus.

Kodo tikrinimo problema yra ta, kad jūs turite jį atskirti. Dažnai sunku išbandyti funkciją, jei ta funkcija iškviečia kitas funkcijas. Norėdami parašyti testą, turite sugalvoti, kaip atsieti funkciją nuo visų kitų. Kitaip tariant, pirmiausia būtinybė išbandyti verčia galvoti apie gerą dizainą.

Tai sukuria geresnį atsietą dizainą, kuriame geriau kontroliuodami dalykus tobulėjate.

Iš pradžių rašant testinius pavyzdžius, iš pradžių gali prireikti laiko, tačiau tai suteikia daug naudos. Kūrėjai pripažįsta, kad anksčiau rašydami kodo eilutes suprato, kad jų sprendimai nėra svarbūs, ir tada vėl pradeda koduoti nuo nulio.

Skirtingai nuo pasenusios kodavimo praktikos, TDD leidžia kūrėjams grįžti prie piešimo lentos ir susitelkti ties lengvos, lanksčios architektūros projektavimu.

Pats testinių atvejų rašymas iš anksto užkerta kelią klaidoms, kurios gali pasirodyti vėliau, taip sutaupydamas laiko, pastangų ir rėmuo.

Galiausiai TDD laikosi geriausios kodavimo praktikos.

TDD skatina gerus kodavimo principus, įskaitant DRY, KISS, YAGNI ir SOLID.

DRY (Don’t Repeat Yourself) principas nurodo kūrėjams vengti kartoti tą patį kodą skirtingose ​​tos pačios sistemos dalyse, todėl jis taip pat kartais vadinamas DIE principu (Duplication Is Evil). DRY rekomenduoja, kad kūrėjai naudotų klases ir funkcijas, norėdami kapsuliuoti sistemos funkcionalumą ir palaikyti nuoseklią pagrindų bazę.

KISS (Laikykis paprasto, kvailo!) Principas kūrėjams pataria ne išradinėti rato, o kurti paprastas ir aiškias architektūras. KISS esmė yra vengti pernelyg inžinerinių sprendimų.

YAGNI (jums to nereikia, jums to nereikia) principas kovoja su auksu. Auksavimas gali atrodyti nekenksmingas, ypač jei kūrėjas nori patobulinti esamas funkcijas, kad sužavėtų klientą. Tačiau tai lemia papildomą kūrimo laiką, dėl kurio projektas gali būti atidėtas arba klientas gali būti nepatenkintas. YAGNI aiškiai nurodo: kūrėjas turėtų įgyvendinti tik priskirtas užduotis ir vengti papildomo funkcionalumo.

SOLID sudaro penki principai viename: viena atsakomybė, atviras-uždarytas, Liskov pakeitimas, sąsajos segregacija ir priklausomybės inversija. Trumpai tariant, SOLID teigia, kad laikantis šių principų programas lengviau prižiūrėti ir testuoti.

Trumpai tariant, TDD padeda sukurti elegantišką ir paprastą kodą, kurį lengva prižiūrėti.

Kaip taikliai pasakė Robertas Martinas.

„Švarus kodas visada atrodo taip, kaip jį parašė tas, kuris tau rūpi“.

Nuorodos

Ekstremalus programavimas: Kentas Beckas.

Agile programinės įrangos kūrimas: Robertas Martinas

Refaktorius: Martinas Fowleris

Apie autorių-:

Ravi Rajan yra pasaulinis IT programų vadovas, įsikūręs Mumbajuje, Indijoje. Jis taip pat yra pašėlęs tinklaraštininkas, Haiku poezijos rašytojas, archeologijos entuziastas ir istorijos maniakas. Susisiekite su „Ravi“ per „LinkedIn“, „Medium“ ir „Twitter“.

Ši istorija paskelbta didžiausiame „Medium“ verslumo leidinyje „The Startup“, kurį seka +438 678 žmonės.

Prenumeruokite ir gaukite mūsų populiariausias istorijas čia.