Mitä on Test Driven Development (TDD)? Esimerkki

by: Thomas Hamilton Thomas Hamilton
Hours Päivitetty

Mitä on Test Driven Development (TDD)?

Test Driven Development (TDD) on ohjelmistokehitystapa, jossa testitapaukset kehitetään määrittelemään ja vahvistamaan, mitä koodi tekee. Yksinkertaisesti sanottuna kunkin toiminnon testitapaukset luodaan ja testataan ensin, ja jos testi epäonnistuu, kirjoitetaan uusi koodi, jotta testi läpäisisi ja koodista tulee yksinkertainen ja virheettömän.

Testilähtöinen kehitys alkaa testien suunnittelulla ja kehittämisellä sovelluksen jokaiselle pienelle toiminnallisuudelle. TDD-kehys kehottaa kehittäjiä kirjoittamaan uutta koodia vain, jos automaattinen testi on epäonnistunut. Tämä välttää koodin päällekkäisyyden. TDD-täysmuoto on testilähtöinen kehitys.

Testattava kehitys

TDD:n yksinkertainen idea on kirjoittaa ja korjata epäonnistuneet testit ennen uuden koodin kirjoittamista (ennen kehitystä). Tämä auttaa välttämään koodin päällekkäisyyttä, kun kirjoitamme pienen määrän koodia kerrallaan läpäistäksemme testit. (Testit ovat vain vaatimusehtoja, jotka meidän on testattava täyttääksemme ne).

Testilähtöinen kehitys on prosessi, jossa kehitetään ja suoritetaan automaattinen testi ennen varsinaista sovelluksen kehittämistä. Siksi TDD:tä kutsutaan joskus myös nimellä Testaa ensimmäistä kehitystä.

Kuinka suorittaa TDD-testi

Seuraavat vaiheet määrittelevät kuinka TDD-testi suoritetaan,

  1. Lisää testi.
  2. Suorita kaikki testit ja katso, epäonnistuuko uusi testi.
  3. Kirjoita joku koodi.
  4. Suorita testit ja Refaktori-koodi.
  5. Toistaa.
Suorita TDD-testi
Testilähtöisen kehityksen viisi askelta

TDD-sykli määrittää

  1. Kirjoita testi
  2. Laita se juoksemaan.
  3. Muuta koodia niin, että se on oikea eli Refaktori.
  4. Toista prosessi.

Muutama selvennys TDD:stä:

  • TDD-lähestymistapa ei ole "testausta" eikä "suunnittelua".
  • TDD ei tarkoita "kirjoita joitakin testejä ja rakenna sitten järjestelmä, joka läpäisee testit.
  • TDD ei tarkoita "tee paljon testausta".

TDD vs. Perinteinen testaus

Alla on tärkein ero testiohjatun kehityksen ja perinteisen testauksen välillä:

TDD-lähestymistapa on ensisijaisesti määrittelytekniikka. Se varmistaa, että lähdekoodisi testataan perusteellisesti vahvistustasolla.

  • Perinteisellä testauksella onnistunut testi löytää yhden tai useamman vian. Se on sama kuin TDD. Kun testi epäonnistuu, olet edistynyt, koska tiedät, että sinun on ratkaistava ongelma.
  • TDD varmistaa, että järjestelmäsi todella täyttää sille määritetyt vaatimukset. Se auttaa rakentamaan luottamustasi järjestelmääsi.
  • TDD:ssä keskitytään enemmän tuotantokoodiin, joka varmistaa, toimiiko testaus oikein. Perinteisessä testauksessa keskitytään enemmän testitapausten suunnitteluun. Osoittaako testi sovelluksen asianmukaisen/epäasianmukaisen suorituksen vaatimusten täyttämiseksi.
  • TDD:ssä saavutat 100 %:n peittotestin. Jokainen koodirivi testataan, toisin kuin perinteinen testaus.
  • Sekä perinteisen testauksen että TDD:n yhdistelmä johtaa järjestelmän testaamisen tärkeyteen järjestelmän täydellisyyden sijaan.
  • In Ketterä mallinnus (AM), sinun tulee "testata tarkoituksella". Sinun tulisi tietää, miksi testaat jotain ja millä tasolla se on testattava.

AIHEESEEN LIITTYVÄT ARTIKKELIT

Mikä on hyväksymis-TDD ja kehittäjä-TDD

TDD-tasoja on kaksi

  1. Hyväksytty TDD (ATDD): ATDD:llä kirjoitat yhden hyväksymistestin. Tämä testi täyttää määrittelyn vaatimuksen tai järjestelmän käyttäytymisen. Kirjoita sen jälkeen juuri sen verran tuotanto-/toiminnallisuuskoodia, että se täyttää hyväksymistestin. Hyväksymistesti keskittyy järjestelmän yleiseen käyttäytymiseen. ATDD tunnettiin myös nimellä Behavioral Driven Development (BDD).
  2. Kehittäjän TDD: Developer TDD:llä kirjoitat yksittäisen kehittäjän testin eli yksikkötestin ja sen jälkeen juuri sen verran tuotantokoodia, että se täyttää testin. Yksikkötesti keskittyy järjestelmän kaikkiin pieniin toimintoihin. Kehittäjä TDD:tä kutsutaan yksinkertaisesti nimellä TDD.ATDD:n ja TDD:n päätavoite on määrittää ratkaisullesi yksityiskohtaiset suoritettavat vaatimukset just in time (JIT) -periaatteella. JIT tarkoittaa vain niiden vaatimusten huomioon ottamista, joita järjestelmässä tarvitaan. Lisää siis tehokkuutta.

Hyväksytty TDD ja kehittäjän TDD

TDD:n skaalaus Agile Model Driven Developmentin (AMDD) avulla

TDD on erittäin hyvä yksityiskohtaisessa määrittelyssä ja validoinnissa. Se ei pysty ajattelemaan suurempia asioita, kuten yleistä suunnittelua, järjestelmän käyttöä tai käyttöliittymää. AMDD ratkaisee ketterän skaalausongelmia, joita TDD ei.

Näin ollen AMDD käytettiin suurempiin ongelmiin.

AMDD:n elinkaari

AMDD:n elinkaari

Mallipohjaisessa kehityksessä (MDD) laajat mallit luodaan ennen lähdekoodin kirjoittamista. Joilla puolestaan ​​on ketterä lähestymistapa?

Yllä olevassa kuvassa jokainen laatikko edustaa kehitystoimintaa.

Visionointi on yksi TDD-prosesseista, joissa ennakoidaan/kuvittellaan testejä, jotka suoritetaan projektin ensimmäisen viikon aikana. Envisioningin päätavoitteena on tunnistaa järjestelmän laajuus ja järjestelmän arkkitehtuuri. Onnistunutta visioimista varten tehdään korkeatasoiset vaatimukset ja arkkitehtuurimallinnus.

Se on prosessi, jossa ei tehdä yksityiskohtaista ohjelmiston/järjestelmän spesifikaatiota, vaan ohjelmiston/järjestelmän vaatimusten tutkiminen määrittelee projektin kokonaisstrategian.

Iteraatio 0: Envisioning

Aliaktivointeja on kaksi.

  1. Alkuperäiset vaatimukset ennakoivat.Järjestelmän korkean tason vaatimusten ja laajuuden tunnistaminen voi kestää useita päiviä. Pääpaino on käyttömallin, alkuperäisen toimialueen mallin ja käyttöliittymämallin (UI) tutkimisessa.
  2. Ensimmäinen Architekninen visio. Järjestelmän arkkitehtuurin tunnistaminen kestää myös useita päiviä. Se mahdollistaa hankkeen teknisten ohjeiden asettamisen. Pääpaino on teknologiakaavioiden, käyttöliittymän (UI) kulun, toimialuemallien ja muutostapausten tutkimisessa.

Iteraatiomallinnus

Tässä tiimin tulee suunnitella jokaiselle iteraatiolle tehtävä työ.

  • Jokaisessa iteraatiossa käytetään ketterää prosessia, eli jokaisen iteroinnin aikana lisätään uusia työkohteita etusijalla.
  • Ensimmäinen korkeampi prioriteettityö huomioidaan. Lisätyt työkohteet voidaan priorisoida uudelleen tai poistaa kohteiden pinosta milloin tahansa.
  • Ryhmä keskustelee, kuinka he aikovat toteuttaa kunkin vaatimuksen. Tätä tarkoitusta varten käytetään mallintamista.
  • Mallinnusanalyysi ja suunnittelu tehdään jokaiselle kyseiselle iteraatiolle toteutettavalle vaatimukselle.

Mallin myrsky

Tämä tunnetaan myös nimellä Just in time -mallinnus.

  • Tässä mallinnusistunnossa on mukana 2/3 jäsenen tiimi, joka keskustelee asioista paperilla tai taululla.
  • Yksi tiimin jäsen pyytää toista mallintamaan heidän kanssaan. Tämä mallinnusistunto kestää noin 5-10 minuuttia. Jossa tiimin jäsenet kokoontuvat jakamaan taulua/paperia.
  • He tutkivat ongelmia, kunnes he eivät löydä ongelman pääsyytä. Juuri ajoissa, jos joku tiimin jäsen tunnistaa ongelman, jonka hän haluaa ratkaista, hän ottaa nopeasti apua muilta tiimin jäseniltä.
  • Muut ryhmän jäsenet tutkivat sitten asiaa ja sitten kaikki jatkavat entiseen tapaan. Sitä kutsutaan myös stand-up-mallinnus- tai asiakkaan laadunvarmistusistunnoiksi.

Test Driven Development (TDD)

  • Se edistää sovelluskoodisi varmistustestausta ja yksityiskohtaisia ​​määrityksiä.
  • Sekä hyväksymistesti (yksityiskohtaiset vaatimukset) että kehittäjätestit (yksikkötesti) ovat TDD:n syötteitä.
  • TDD tekee koodista yksinkertaisemman ja selkeämmän. Sen avulla kehittäjä voi ylläpitää vähemmän dokumentaatiota.

Revnäkemykset

  • Tämä on valinnaista. Se sisältää kooditarkastuksia ja mallitarkastuksia.
  • Tämä voidaan tehdä jokaiselle iteraatiolle tai koko projektille.
  • Tämä on hyvä vaihtoehto antaa palautetta projektista.

Test Driven Development (TDD) vs. Agile Model Driven Development (AMDD)

TDD AMDD
TDD lyhentää ohjelmoinnin takaisinkytkentäsilmukkaa AMDD lyhentää mallinnuksen takaisinkytkentäsilmukkaa.
TDD on yksityiskohtainen erittely AMDD toimii suurempiin ongelmiin
TDD edistää korkealaatuisen koodin kehittämistä AMDD edistää korkealaatuista viestintää sidosryhmien ja kehittäjien kanssa.
TDD puhuu ohjelmoijille AMDD puhuu Business Analyst, sidosryhmät ja data-ammattilaiset.
TDD ei-visuaalisesti suuntautunut AMDD visuaalisesti suuntautunut
TDD:llä on rajoitettu laajuus ohjelmistotöihin AMDD:llä on laaja soveltamisala, mukaan lukien sidosryhmät. Siihen kuuluu työskentely yhteisymmärryksen saavuttamiseksi
Molemmat tukevat evoluution kehitystä ---------------

TDD-kehykset

Tässä on luettelo parhaista testipohjaisista kehityskehyksistä (TDD).

  1. Junit
  2. TestNG
  3. csUnit ja NUnit
  4. Rspec

Opitaan nyt testilähtöistä kehitystä esimerkin avulla.

Esimerkki TDD:stä

Tässä tässä Test Driven Development -esimerkissä määritämme luokan salasanan. Tällä luokalla yritämme täyttää seuraavat ehdot.

Salasanan hyväksymisen ehto:

  • Salasanan tulee olla 5-10 merkkiä pitkä.

Ensin tässä TDD-esimerkissä kirjoitamme koodin, joka täyttää kaikki yllä olevat vaatimukset.

Esimerkki TDD:stä

Skenaario 1: Testin suorittamiseksi luomme luokan PasswordValidator ();

Esimerkki TDD:stä

Suoritamme luokan TestPassword ();

Lähtö on HYVÄKSYTTY alla olevan kuvan mukaisesti;

ulostulo:

Esimerkki TDD:stä

Skenaario 2: Tässä näemme menetelmässä TestPasswordLength (), että luokan PasswordValidator esiintymää ei tarvitse luoda. Instanssi tarkoittaa luomista objekti luokasta viittaamaan kyseisen luokan jäseniin (muuttujiin/menetelmiin).

Esimerkki TDD:stä

Poistamme luokan PasswordValidator pv = new PasswordValidator () koodista. Voimme soittaa on voimassa () menetelmä suoraan PasswordValidator. IsValid ("Abc123"). (Katso kuva alla)

Joten refaktoroimme (muutamme koodia) seuraavasti:

Esimerkki TDD:stä

Skenaario 3: Refaktoroinnin jälkeen tulos näyttää epäonnistuneen tilan (katso kuva alla), tämä johtuu siitä, että olemme poistaneet esiintymän. Ei siis viitata ei-staattiseen menetelmään isValid ().

Esimerkki TDD:stä

Joten meidän on muutettava tätä menetelmää lisäämällä "staattinen" sana ennen Boolen arvoa julkiseksi staattiseksi boolean isValid (merkkijonon salasana). Refactoring Class PasswordValidator () poistaa yllä olevan virheen testin läpäisemiseksi.

Esimerkki TDD:stä

lähtö:

Kun olet tehnyt muutoksia luokkaan PassValidator (), jos suoritamme testin, tulos HYVÄKSYTTYYN, kuten alla on esitetty.

Esimerkki TDD:stä

TDD:n edut

Seuraavat ovat ohjelmistosuunnittelun testilähtöisen kehityksen tärkeimmät edut:

Varhainen virheilmoitus.

  • Kehittäjät testaavat koodiaan, mutta tietokantamaailmassa tämä koostuu usein manuaalisista testeistä tai kertaluonteisista skripteistä. TDD:n avulla rakennat ajan mittaan sarjan automaattisia testejä, jotka sinä ja kuka tahansa muu kehittäjä voitte suorittaa uudelleen halutessaan.

Paremmin suunniteltu, selkeämpi ja laajennettavissa oleva koodi.

  • Se auttaa ymmärtämään, kuinka koodia käytetään ja miten se on vuorovaikutuksessa muiden moduulien kanssa.
  • Se johtaa parempaan suunnittelupäätökseen ja ylläpidettävämpään koodiin.
  • TDD mahdollistaa pienemmän koodin kirjoittamisen, jolla on yksi vastuu, pikemminkin kuin monoliittiset menettelyt, joissa on useita vastuita. Tämä tekee koodista helpompi ymmärtää.
  • TDD pakottaa myös kirjoittamaan vain tuotantokoodia läpäistäkseen testit käyttäjän vaatimusten perusteella.

Luottamus Refaktorille

  • Jos muokkaat koodia, koodissa voi olla katkoksia. Joten kun sinulla on joukko automaattisia testejä, voit korjata nämä tauot ennen julkaisua. Asianmukainen varoitus annetaan, jos automaattisia testejä käytettäessä havaitaan taukoja.
  • TDD:n käytön pitäisi johtaa nopeampaan, laajennettavampaan koodiin, jossa on vähemmän bugeja, jotka voidaan päivittää minimaalisilla riskeillä.

Hyvä ryhmätyöhön

  • Kun tiimin jäseniä ei ole, muut tiimin jäsenet voivat helposti poimia koodin ja käsitellä sitä. Se auttaa myös tiedon jakamista, mikä tekee tiimistä kokonaisvaltaisen tehokkaamman.

Hyvä kehittäjille

  • Vaikka kehittäjien on käytettävä enemmän aikaa TDD-testitapausten kirjoittamiseen, virheenkorjaukseen ja uusien ominaisuuksien kehittämiseen kuluu paljon vähemmän aikaa. Kirjoitat puhtaamman, vähemmän monimutkaisen koodin.

Yhteenveto

  • TDD tarkoittaa testilähtöistä kehitystä.
  • TDD merkitys: Se on prosessi, jossa koodia muokataan aiemmin suunnitellun testin läpäisemiseksi.
  • Se korostaa enemmän tuotantokoodia kuin testitapauksen suunnittelua.
  • Testilähtöinen kehitys on prosessi, jossa koodia muokataan aiemmin suunnitellun testin läpäisemiseksi.
  • In Ohjelmistotuotanto, Se tunnetaan joskus nimellä "Testaa ensimmäinen kehitys."
  • TDD-testaus sisältää koodin uudelleenmuodostamisen eli jonkin koodimäärän muuttamisen/lisäämisen olemassa olevaan koodiin vaikuttamatta koodin toimintaan.
  • TDD-ohjelmointia käytettäessä koodista tulee selkeämpi ja helpompi ymmärtää.

Saatat tykätä: