Zakaj Test Driven Development (TDD) je najboljši način za robustno kodiranje.

Najprej napišite preizkuse enot, nato napišite kodo.

Slikovni krediti: Pexels.com

Pred nekaj leti, ko sem prvič slišal za "Test Driven Development", sem bil skeptičen.

Zamisel, da "najprej napiši enote za pisanje, nato pa napiši kodo", se mi je znebila.

Zakaj ne bi bil? Najprej napišete svoje enote? Kdo bi naredil takšno goofy stvar?

Ampak do takrat sem bil poklicni programer in sem videl, da v industriji stvari prihajajo in odhajajo. Znal sem bolje, kot da kaj zavrnem iz rok, še posebej, ko so se razvijalci tako pogovarjali.

Zato sem se posvetoval s svojim prijateljem, ki mi je pokazal osnovni primer.

Ta osnovni primer ima razred LCL_SUM z metodo SUM. Ta metoda je odgovorna za dodajanje številk. Število vzame kot uvozni parameter in ga nato doda k rezultatu. To metodo poimenujemo kot proizvodno metodo.

Koda za razred je bila takšna:

RAZREDNA OPREDELITEV lcl_sum.
JAVNO ODDELEK
METODE: POMEMBNI UVOZ iv_1 VRSTA i
VRNITEV VREDNOSTI (rv_sum) VRSTA i.
ENDCLASS. „Lcl_sum OPREDELITEV
*
ZAČETEK IZBORA
* Tu še ni nič
*
*
RAZRED IZVEDBE lcl_sum.
METODA ŠUMA.
rv_sum = iv_1 * iv_1. "Namerna napaka (pomnožim namesto dodajanja)
ENDMETHOD. "Seštevek
ENDCLASS. „IZVAJANJE lcl_sum.

Nastavitev testnega razreda

Zdaj ustvarite razred, ki deluje kot testni razred. V SAP bi morali pri določanju razreda dodati ključno besedo ZA TESTIRANJE. Ta dodatek ločuje ta razred od proizvodne kode.

RAZRED lcl_test OPREDELITEV ZA PRESKUŠANJE
JAVNO ODDELEK
METODE: m_sum ZA TESTIRANJE.
ENDCLASS. „Lcl_test OPREDELITEV
*
RAZRED lcl_test IZVAJANJE.
METHOD m_sum.
ENDMETHOD. „M_sum
ENDCLASS. "Lcl_test IZVAJANJE

Izvedba preskusne metode

Pri tej preskusni metodi morate preveriti proizvodno kodo. Torej, da bi lahko preizkusili metodo SUM LCL_SUM, bi morali sprožiti referenco predmeta na LCL_SUM, pokličite metodo SUM in pošljete dvomljivo vrednost.

Na podlagi vrednosti Dummy vam bo metoda poslala rezultat - dejanski rezultat iz metode. Na podlagi Dummy vrednosti veste, kakšna bi bila pričakovana vrednost. Npr. Če številko 3 prepustite metodi SUM, vam bo prinesel rezultat 6, kolikor doda 3.

Ko prejmete dejanski rezultat iz proizvodne kode ali metode, ki jo preizkušate, morate primerjati rezultate. Če se dejanski in pričakovani ne ujemata, morate obvestiti sistem, da z dejanskim vs Pričakovano nekaj ni v redu in pokazati ustrezno sporočilo.

RAZRED lcl_test IZVAJANJE.
METHOD m_sum.
PODATKI: o_cut VRSTA REF TO lcl_sum.
PODATKI: lv_result TIP i.
*
USTVARJITE OBJEKT o_cut.
lv_result = o_cut-> vsota (3).
*
cl_aunit_assert => assert_equals (
EXP = 6
dejanje = lv_result
msg = 'nekaj narobe v izhodu'
).
ENDMETHOD. „M_sum
ENDCLASS. "Lcl_test IZVAJANJE

Rezultati enotnega testa

To mi pravi, da je pri izvajanju proizvodne metode nekaj narobe.

Ja, če natančno pogledate izvajanje metode SUM, imam tipko - namesto uporabe seštevanja sem uporabil množenje. Torej bi ga popravil in znova izvedel test, da ga uspešno izvedem.

Priklenjen sem bil na TDD. Prava beseda bi bila prava beseda.

Neverjetno je bil zelo skrajšani cikel razvoja in testiranja.

Bil sem navajen pisati kodo večino ure, preden sem jo skušal sestaviti ali zagnati. Toda tu se je koda izvajala in preizkušala vsake dve minuti.

Skratka, TDD se realizira s kratkimi razvojnimi cikli, ki sledijo pravilu »najprej napišite preizkuse enote, nato napišite kodo, nato refaktor in nato ponovite.« Preizkusi enot so avtomatizirani testi, ki preverjajo, ali funkcije delujejo po pričakovanjih. Vaš prvi preizkus enote naj ne bo uspešen, saj je napisan, preden imate celo kodno bazo.

Kodo preskusnega primera dodate malo. Nekaj ​​dodate v proizvodno kodo. Oba toka kode rasteta hkrati v komplementarne komponente. Testi ustrezajo proizvodni kodi, kot da protitelo ustreza antigenu.

Ta ukrep razvijalcem preprečuje, da bi napisali nepotrebno kodo, ki ni v skladu z dano preizkušnjo.

In celoten integriran pristop ponuja razvijalcu koristi.

Popravite slabo kodo, ne da bi karkoli zlomili.

Kadarkoli zagledate slabo kodo, zasukate oči, molite Boga in izgovorite eno od obeh izjav.

· »To je nered. Mislim, da ga moram nekako popraviti. "

· "Ne dotikam se ga."

V vsakem primeru gre za element strahu. Pravzaprav negotovost.

Kaj, če moja koda prekine obstoječo funkcionalnost?

TDD vam pomaga natančno premagati to negotovost.

Pomembno je poudariti, da se v okolju TDD razvijalci osredotočijo na izvajanje testov, da preprečijo napake, namesto da jih odstranijo po pisanju kode. To je ena najmočnejših prednosti TDD. Ko imate nabor testov, ki jim zaupate, izgubite strah pred spremembami. Ko vidite slabo kodo, jo preprosto očistite na kraju samem.

In čim bolj je koda tista, ki jo mora vaša ekipa vložiti v nove funkcije ali spremeniti obstoječo kodno bazo, manj truda.

TDD uveljavlja dokumentacijo.

Dick Brandon ga je, ko je opazoval, udaril po nohtu.

„Dokumentacija je kot seks; kadar je dobro, je zelo, zelo dobro, in ko je slabo, je bolje kot nič. "

Dokumentacija je ricinusovo olje programiranja. Menedžerji menijo, da je to dobro za programerje, programerji pa ga sovražijo!

Eden od pogostih razlogov za nastanek plazenja obsega je pomanjkanje dokumentacije z jasno opredeljenimi zahtevami. To težavo je mogoče odpraviti s testno usmerjenim razvojem.

V okolju TDD razvijalci napišejo preizkuse enot, da preizkusijo določene segmente kode. Preizkusi enot služijo kot specifikacije, ki opisujejo natančne lastnosti, ki jih je treba uporabiti. Zato natančno določeni testi razvijalcem preprečijo pisanje odvečne kode.

In ti enotni testi so dokumenti. Opisujejo zasnovo najnižje ravni sistema. So nedvoumni, natančni, napisani v jeziku, ki ga občinstvo razume, in so tako formalni, da jih izvajajo. So najboljša vrsta dokumentacije na nizki ravni, ki lahko obstaja.

TDD pomaga pri boljšem oblikovanju

Temeljni predpogoj TDD je, da morate pred pisanjem kode napisati svoje enote testnih primerov.

Težava s preskusno kodo je, da jo morate izolirati. Funkcijo je pogosto težko preizkusiti, če ta funkcija pokliče druge funkcije. Če želite napisati ta test, morate na neki način razvezati funkcijo od vseh ostalih. Z drugimi besedami, potreba po testiranju vas najprej prisili, da razmišljate o dobri zasnovi.

Tako nastane boljši, nevezan dizajn, v katerem imate boljši nadzor nad stvarmi, ko se koda razvija.

Medtem ko pisanje testnih primerov vnaprej lahko porabi nekaj časa, vendar to prinaša veliko koristi. Razvijalci priznavajo, da so prej pisali kode, se zavedajo, da so bile njihove rešitve nepomembne, in nato ponovno začeli s kodiranjem.

Za razliko od zastarelih kodirskih praks, TDD omogoča razvijalcem, da se vrnejo na risalno ploščo in se osredotočijo na oblikovanje lahke, prožne arhitekture vnaprej.

In že samo dejstvo pisanja testnih primerov vnaprej preprečuje morebitne napake, ki bi se lahko pojavile pozneje, s čimer bi prihranili čas, trud in zgago.

In nazadnje TDD sledi najboljšim praksam kodiranja.

TDD spodbuja dobra načela kodiranja, vključno z DRY, KISS, YAGNI in SOLID.

Načelo DRY (Ne ponavljaj sebe) razvijalcem nalaga, naj se izogibajo ponavljanju iste kode v različnih delih istega sistema, zato se včasih imenuje tudi načelo DIE (Podvajanje je zlo). DRY priporoča razvijalcem, da uporabljajo razrede in funkcije, da vgradijo sistemsko funkcionalnost in vzdržujejo dosledno kodno bazo.

Načelo KISS (Keep it Simple, Stupid!) Razvijalcem svetuje, naj ne izumljajo kolesa, temveč da gradijo preproste in jasne arhitekture. Bistvo KISS je izogniti se preoblikovanim rešitvam.

Načelo YAGNI (You Ainth Gonna Need It) se bori proti pozlačevanju. Pokrivanje z zlatom se lahko zdi neškodljivo, še posebej, če razvijalci želijo izboljšati obstoječo funkcionalnost, da bi navdušili kupca. Vendar pa ima za to dodatni čas razvoja, ki lahko povzroči zamudo pri projektu ali nezadovoljnega kupca. YAGNI jasno določa: razvijalci naj izvajajo samo dodeljene naloge in se izogibajo dodajanju pretirane funkcionalnosti.

SOLID je sestavljen iz petih načel v enem: ena sama odgovornost, odprto-zaprto, nadomestitev Liskov, segregacija vmesnikov in inverzija odvisnosti. Na kratko, SOLID navaja, da upoštevanje teh načel olajša vzdrževanje in testiranje aplikacij.

Na kratko, TDD pomaga pri ustvarjanju elegantne in preproste kode, ki jo je enostavno vzdrževati.

Kot je pravilno povedal Robert Martin.

"Čista koda je vedno videti, kot da jo je napisal nekdo, ki ji je mar."

Reference

Ekstremno programiranje: Kent Beck.

Agile Razvoj programske opreme: Robert Martin

Refactoring: Martin Fowler

O avtorju-:

Ravi Rajan je vodja globalnega IT programa s sedežem v Bombaju v Indiji. Je tudi navdušen bloger, pisatelj poezije Haiku, ljubitelj arheologije in zgodovinski manijak. Povežite se z Ravijem na LinkedIn, Medium in Twitterju.

Ta zgodba je objavljena v največji podjetniški publikaciji The Startup, ki ji sledi +438.678 ljudi.

Naročite se za prejem naših vrhunskih zgodb tukaj.