Miksi testiohjattu kehitys (TDD) on paras tapa vankkaan koodaukseen.

Kirjoita ensin yksikkötestit ja kirjoita sitten koodi.

Kuvalainat: Pexels.com

Muutama vuosi sitten, kun kuulin ensimmäisen kerran ”Test Driven Development” -standardista, olin skeptinen.

Itse ajatus ”ensin kirjoita yksikkötesteistä, sitten kirjoita koodi” oli minulle gibberish.

Miksi se ei olisi? Kirjoita ensin yksikkötestisi? Kuka tekisi niin hölmö asian?

Mutta olin siihen mennessä ollut ammattimainen ohjelmoija 10 vuotta, ja olin nähnyt asioiden tulevan ja menevän teollisuudessa. Tiesin paremmin kuin hylätä mitään käsistä, varsinkin kun kehittäjät suhtautuivat siihen niin hyvin.

Joten kuulin ystävääni, joka näytti minulle perusajatuksen.

Tällä perusesimerkillä on luokka LCL_SUM menetelmällä SUM. Tämän menetelmän vastuulla on lisätä numeroita. Se vie numeron tuontiparametrina ja lisää sen sitten itsensä tuloksen saamiseksi. Kutsutaan tätä menetelmää tuotantomenetelmäksi.

Luokan koodi oli seuraava:

LUOKAN lcl_sum MÄÄRITELMÄ.
JULKINEN OSA.
MENETELMÄT: SUM TUONTI iv_1 TYYPPI i
PALAUTTAVA ARVO (rv_sum) TYYPPI i.
ENDCLASS. ”Lcl_sum MÄÄRITELMÄ
*
START-OF-VALINTA.
* Ei mitään täällä vielä
*
*
LUOKAN lcl_sum TOTEUTUS.
MENETELMÄN SUMMA.
rv_sum = iv_1 * iv_1. ”Tahdonvoimainen virhe (kerrotaan lisäämisen sijaan)
ENDMETHOD. "summa
ENDCLASS. ”Lcl_sum TOTEUTUS.

Testiluokan asetus

Luo nyt luokka, joka toimii testiluokana. SAP: iin sinun olisi lisättävä avainsana TESTAAMINEN luokkaa määritettäessä. Tämä lisäys erottaa tämän luokan tuotekoodista.

LUOKAN lcl_test MÄÄRITELMÄ TESTAAMISEKSI
JULKINEN OSA.
MENETELMÄT: m_sum testausta varten.
ENDCLASS. ”Lcl_test MÄÄRITELMÄ
*
LUOKAN lcl_test-TOTEUTUS.
METHOD m_sum.
ENDMETHOD. ”m_sum
ENDCLASS. ”Lcl_test TOTEUTUS

Testimenetelmän toteutus

Tässä testimenetelmässä sinun on tehtävä - Testaa tuotekoodi. Joten voidaksesi testata LCL_SUM-menetelmän SUM, sinun on välittömitettävä objektiviittaus LCL_SUM: ään, kutsutaan menetelmä SUM: ksi lähettämällä näennäisarvo.

Nukke-arvon perusteella menetelmä lähettää sinulle tuloksen - menetelmän todellisen tuloksen. Nukke-arvon perusteella tiedät, mikä olisi odotettu arvo. Esim. Jos siirrät luvun 3 SUM-menetelmään, se antaisi sinulle tuloksen 6, koska se lisää arvoon 3.

Kun olet saanut todellisen tuloksen testattavasta tuotekoodista tai menetelmästä, sinun on vertailtava tuloksia. Jos todellinen vs. odotettu ei vastaa, sinun on ilmoitettava järjestelmälle, että todellisessa vs. odotettavissa olevassa on jotain vikaa, ja näytettävä sopiva viesti.

LUOKAN lcl_test-TOTEUTUS.
METHOD m_sum.
TIEDOT: o_cut TYYPPITIEDOT Lcl_sum.
TIEDOT: lv_tulos TYYPPI i.
*
LUO OBJEKTI o_cut.
lv_tulos = o_cut-> summa (3).
*
cl_aunit_assert => assert_equals (
EXP = 6
act = lv_result
msg = 'jotain vikaa tulostuksessa'
).
ENDMETHOD. ”m_sum
ENDCLASS. ”Lcl_test TOTEUTUS

Yksikkötestin tulokset

Tämä kertoo minulle, että tuotantomenetelmien toteutuksessa on jotain vikaa.

Joo, jos tarkastellaan tarkkaan SUM-menetelmän toteutusta, minulla on kirjoitusvirhe - summituksen käytön sijaan, olin käyttänyt kertolaskua. Joten korjaan sen ja suoritan testin uudelleen suorittaakseni sen onnistuneesti.

Olin koukussa TDD: hen. Flabbergasted olisi oikea sana.

Hämmästyttävää oli kehitystyön ja testauksen erittäin lyhentynyt sykliaika.

Olin tottunut kirjoittamaan koodia paremman tunnin tuntiin ennen kuin yritin kääntää tai suorittaa sitä. Mutta täällä koodi oli käynnissä ja testattu joka toinen minuutti.

Niinpä, pähkinänkuoressa, TDD toteutetaan lyhyillä kehityssykleillä, jotka seuraavat sääntöä: “ensin kirjoita yksikkötestejä, kirjoita sitten koodi, sitten refaktori ja toista sitten”. Yksikkötestit ovat automaattisia testejä, jotka tarkistavat toimivatko toiminnot odotetusti. Aivan ensimmäinen yksikkötestisi on epäonnistunut, koska se on kirjoitettu ennen kuin sinulla edes ole mitään emäskantaa.

Lisäät hiukan testitapauskoodiin. Lisäät hiukan tuotekoodiin. Nämä kaksi koodivirraa kasvavat samanaikaisesti komplementaarisiksi komponenteiksi. Testit sopivat tuotantokoodiin, kuten vasta-aine sopii antigeenille.

Tämä toimenpide estää kehittäjiä kirjoittamasta tarpeetonta koodia, joka ei vastaa annettua testiä.

Ja tämä koko integroitu lähestymistapa tarjoaa litaania etuja kehittäjälle.

Korjaat huonon koodin rikkomatta mitään.

Aina, kun näet huonon koodin, käännät silmäsi, rukoilet Jumalaa ja lausut yhden toisen kahdesta lausunnosta.

· ”Tämä on sotku. Luulen, että minun on korjattava se jotenkin ”.

· "En koske sitä."

Kummassakin tapauksessa on mukana pelko. Itse asiassa epävarmuus.

Entä jos koodini rikkoa nykyisen toiminnallisuuden?

TDD auttaa sinua tarkalleen voittamaan tämän epävarmuuden.

On tärkeää huomata, että TDD-ympäristössä kehittäjät keskittyvät testien suorittamiseen virheiden estämiseksi sen sijaan, että ne poistettaisiin koodin kirjoittamisen jälkeen. Tämä on yksi TDD: n tehokkaimmista eduista. Kun sinulla on luotettavien testien sarja, menetät kaiken pelon tehdä muutoksia. Kun näet virheellisen koodin, puhdistat sen vain paikan päällä.

Ja mitä siistimpi koodi on, sitä vähemmän työtä joukkueesi on tehtävä uusien ominaisuuksien lisäämiseen tai olemassa olevan kooditietokannan muuttamiseen.

TDD pakottaa dokumentoinnin.

Dick Brandon osui siihen bang kynsiin, kun hän havaitsi.

”Dokumentaatio on kuin seksiä; kun se on hyvä, se on erittäin, erittäin hyvä, ja kun se on huono, se on parempi kuin ei mitään. "

Dokumentaatio on ohjelmoinnin risiiniöljyä. Johtajien mielestä on hyvä, että ohjelmoijat ja ohjelmoijat vihaavat sitä!

yksi yleinen syy, miksi laajuuden hiipiminen tapahtuu, on selvästi määriteltyjen asiakirjojen puutteellisuus. Tätä ongelmaa voidaan lievittää testilähtöisellä kehittämisellä.

TDD-ympäristössä kehittäjät kirjoittavat yksikkötestejä tiettyjen koodisegmenttien testaamiseksi. Yksikkötestit toimivat spesifikaatioina, jotka kuvaavat tarkat ominaisuudet, jotka tulisi toteuttaa. Siksi hyvin määritellyt testit estävät kehittäjiä kirjoittamasta turhaa koodia.

Ja nämä yksikkötestit ovat asiakirjoja. Ne kuvaavat järjestelmän alimman tason suunnittelua. Ne ovat yksiselitteisiä, tarkkoja, kirjoitettu kielellä, jota yleisö ymmärtää, ja ovat niin muodollisia, että suorittavat. Ne ovat paras matalan tason dokumentaatio, jota voi olla.

TDD auttaa paremmassa suunnittelussa

TDD: n perusedellytys on, että sinun on kirjoitettava yksikkötestikohdat ennen koodin kirjoittamista.

Koodin testauksen ongelma on, että sinun on eristettävä tämä koodi. Toiminnon testaaminen on usein vaikeaa, jos toiminto kutsuu muita toimintoja. Testin kirjoittamiseksi sinun on keksittävä jokin tapa erottaa toiminto kaikista muista. Toisin sanoen tarve testata ensin pakottaa sinut pohtimaan hyvää suunnittelua.

Tämä luo paremman, irrotetun mallin, jossa sinulla on parempi hallita asioita koodin kehittyessä.

Testitapausten kirjoittaminen etukäteen voi kuluttaa aikaa aluksi, mutta siitä on paljon hyötyä. Kehittäjät myöntävät, että aiemmin he kirjoittivat aiemmin koodiriviä, ymmärsivät ratkaisujensa olevan merkityksettömiä, ja aloittavat sitten koodauksen uudelleen tyhjästä.

Toisin kuin vanhentuneet koodauskäytännöt, TDD antaa kehittäjille mahdollisuuden palata piirtotauluun ja keskittyä kevyt, joustavan arkkitehtuurin suunnitteluun etukäteen.

Ja tosiasia, että testitapausten kirjoittaminen etukäteen estää mahdollisesti myöhemmin ilmaantuvia virheitä, mikä säästää aikaa, vaivaa ja närästystä.

Ja viimeiseksi, TDD noudattaa parhaita koodauskäytäntöjä.

TDD edistää hyviä koodausperiaatteita kuten DRY, KISS, YAGNI ja SOLID.

DRY (älä toista itseäsi) -periaate kehottaa kehittäjiä välttämään saman koodin toistamista saman järjestelmän eri osissa, minkä vuoksi sitä kutsutaan joskus myös DIE-periaatteeksi (Duplication Is Evil). DRY suosittelee, että kehittäjät käyttävät luokkia ja toimintoja kapseloimaan järjestelmän toiminnot ja ylläpitämään johdonmukaista kooditietokantaa.

KISS (Keep it Simple, Stupid!) -Periaate kehottaa kehittäjiä olemaan keksimättä pyörää uudelleen, vaan rakentamaan yksinkertaisia ​​ja selkeitä arkkitehtuureja. KISS: n ydin on välttää ylimitoitettuja ratkaisuja.

YAGNI (Sinä et tarvitse sitä) -periaate taistelee kultapinnoitusta vastaan. Kultapinnoitus saattaa vaikuttaa vaarattomalta, etenkin jos kehittäjä haluaa parantaa olemassa olevia toimintoja asiakkaan ilahduttamiseksi. Se johtaa kuitenkin ylimääräiseen kehitysaikaan, mikä voi aiheuttaa projektin viivästymisen tai tyytymättömän asiakkaan. YAGNI tekee selväksi: kehittäjän tulee toteuttaa vain määritetyt tehtävät ja välttää liiallisen toiminnallisuuden lisäämistä.

SOLID koostuu viidestä periaatteesta yhdessä: yksi vastuu, avoin-suljettu, Liskov-substituutio, rajapintojen segregaatio ja riippuvuusversio. Lyhyesti sanottuna SOLID toteaa, että näiden periaatteiden noudattaminen helpottaa sovellusten ylläpitoa ja testaamista.

Lyhyesti sanottuna, TDD auttaa luomaan tyylikkään ja yksinkertaisen koodin, jota on helppo ylläpitää.

Kuten Robert Martin on osuvasti sanonut.

"Puhdas koodi näyttää aina siltä, ​​että sen on kirjoittanut välittäjä."

Viitteet

Äärimmäinen ohjelmointi: Kent Beck.

Ketterä ohjelmistokehitys: Robert Martin

Valmistus: Martin Fowler

Kirjailijasta-:

Ravi Rajan on globaali IT-ohjelmien johtaja, joka sijaitsee Mumbaista, Intiasta. Hän on myös innokas bloggaaja, Haiku-runokirjoittaja, arkeologian harrastaja ja historiamiaksi. Ota yhteys Raviin LinkedInissä, Mediumissa ja Twitterissä.

Tämä tarina on julkaistu Mediumin suurimmassa yrittäjyysjulkaisussa The Startup, jota seuraavat +438 678 ihmistä.

Tilaa saadaksesi parhaita tarinoitamme täältä.