Mikä on testikäyttöinen kehitys (TDD)? Opetusohjelma esimerkillä

Testiohjattu kehitys

Test Driven Development (TDD) on ohjelmistokehitystapa, jossa testitapauksia kehitetään määrittämään ja vahvistamaan, mitä koodi tekee. Yksinkertaisesti sanottuna kunkin toiminnon testitapaukset luodaan ja testataan ensin ja jos testi epäonnistuu, uusi koodi kirjoitetaan testin läpäisemiseksi ja koodin tekemiseksi yksinkertaiseksi ja virheettömäksi.

Testiohjattu kehitys alkaa testausten suunnittelusta ja kehittämisestä sovelluksen jokaiselle pienelle toiminnallisuudelle. TDD kehottaa kehittäjiä kirjoittamaan uuden koodin vain, jos automaattinen testi on epäonnistunut. Tämä välttää koodin päällekkäisyyden. TDD: n koko muoto on testipohjainen kehitys.

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

Testiohjattu kehitys on prosessi automaattisen testauksen kehittämiseksi ja suorittamiseksi ennen sovelluksen varsinaista kehittämistä. Siksi TDD: tä kutsutaan joskus myös nimellä Test First Development.

Tässä opetusohjelmassa opit lisää

• Kuinka suorittaa TDD-testi
• TDD vs. Perinteinen testaus
• Mitä on TDD-hyväksyntä ja Developer TDD
• TDD: n skaalaus ketterällä mallipohjaisella kehityksellä (AMDD)
• Test Driven Development (TDD) vs. Ketterä malliohjattu kehitys (AMDD)
• Esimerkki TDD: stä
• TDD: n edut

Kuinka suorittaa TDD-testi

Seuraavissa vaiheissa määritetään, miten TDD-testi suoritetaan,

1. Lisää testi.
2. Suorita kaikki testit ja katso jos jokin uusi testi epäonnistuu.
3. Kirjoita koodi.
4. Suorita testit ja Refactor-koodi.
5. Toistaa.

TDD-sykli määrittelee

1. Kirjoita testi
2. Tee se ajamaan.
3. Muuta koodi oikeaksi eli Refactor.
4. Toista prosessi.

Joitakin selityksiä TDD: stä:

• TDD ei ole "testaus" eikä "suunnittelu".
• TDD ei tarkoita "kirjoita joitain testejä ja rakenna sitten järjestelmä, joka läpäisee testit.
• TDD ei tarkoita "tee paljon testejä".

TDD vs. Perinteinen testaus

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

• Perinteisessä testauksessa 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ääritellyt vaatimukset. Se auttaa rakentamaan luottamusta järjestelmään.
• TDD: ssä keskitytään enemmän tuotantokoodiin, joka tarkistaa, toimiiko testaus oikein. Perinteisessä testauksessa painopiste on enemmän testitapausten suunnittelussa. Ovatko testit osoittaneet sovelluksen asianmukaisen / virheellisen suorituksen vaatimusten täyttämiseksi?
• TDD: ssä saavutat 100% 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.
• Ketterässä mallinnuksessa (AM) sinun tulisi "testata tarkoituksella". Sinun pitäisi tietää, miksi testaat jotain ja minkä tason se on testattava.

Mitä on TDD-hyväksyntä ja Developer TDD

TDD: tä on kaksi tasoa

1. Hyväksyntä TDD (ATDD): ATDD: llä kirjoitat yhden hyväksymistestin. Tämä testi täyttää spesifikaation vaatimukset tai järjestelmän käyttäytymisen. Sen jälkeen kirjoita vain tarpeeksi tuotanto- / toiminnallisuuskoodia kyseisen hyväksymistestin suorittamiseksi. Hyväksyntätesti keskittyy järjestelmän yleiseen käyttäytymiseen. ATDD tunnettiin myös nimellä Behavioral Driven Development (BDD).
2. Kehittäjän TDD: Kehittäjän TDD: n avulla kirjoitat yhden kehittäjätestin eli yksikkötestin ja sitten vain tarpeeksi tuotantokoodin kyseisen testin täyttämiseksi. Yksikkötesti keskittyy järjestelmän kaikkiin pieniin toimintoihin. Kehittäjän TDD: tä kutsutaan yksinkertaisesti nimellä TDD.

   ATDD: n ja TDD: n päätavoitteena on määritellä ratkaisulle yksityiskohtaiset, suoritettavat vaatimukset juuri oikeaan aikaan (JIT) -periaatteella. JIT tarkoittaa vain järjestelmässä tarvittavien vaatimusten huomioon ottamista. Joten lisää tehokkuutta.

TDD: n skaalaus ketterällä mallipohjaisella kehityksellä (AMDD)

TDD on erittäin hyvä yksityiskohtaisissa määrittelyissä ja validoinnissa. Se epäonnistuu ajatellen suurempia asioita, kuten yleistä suunnittelua, järjestelmän käyttöä tai käyttöliittymää. AMDD korjaa ketterät skaalausongelmat, joita TDD ei.

Siten AMDD: tä käytettiin suurempiin ongelmiin.

AMDD: n elinkaari.

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

Yllä olevassa kuvassa kukin ruutu edustaa kehitystoimintaa.

Visiointi on yksi TDD-prosesseista ennustaa / kuvitella testejä, jotka suoritetaan projektin ensimmäisen viikon aikana. Visioinnin päätavoitteena on tunnistaa järjestelmän laajuus ja järjestelmän arkkitehtuuri. Menestyksen onnistumiseksi tehdään korkean tason vaatimukset ja arkkitehtuurimallinnus.

Se on prosessi, jossa ei tehdä tarkkaa ohjelmistojen / järjestelmien määrittelyä, mutta tutkitaan ohjelmistojen / järjestelmien vaatimuksia, mikä määrittelee projektin kokonaisstrategian.

1. Iteraatio 0: Visiointi

Aliaktivointeja on kaksi.

1. Alustavien vaatimusten visiointi.

   Voi kestää useita päiviä järjestelmän korkean tason vaatimusten ja laajuuden tunnistamiseen. Pääpaino on käyttömallin, alustavan verkkotunnusmallin ja käyttöliittymämallin (UI) tutkimiseen.

2. Alkuperäinen arkkitehtoninen visiointi.

   Järjestelmän arkkitehtuurin tunnistaminen vie myös useita päiviä. Sen avulla voidaan asettaa teknisiä ohjeita projektille. Pääpaino on tutkia teknologiakaavioita, käyttöliittymän kulkua, toimialueiden malleja ja muutostapauksia.

2. Iteraatiomallinnus:

   Tässä tiimin on suunniteltava työ, joka tehdään jokaiselle iteraatiolle.

• Ketterää prosessia käytetään jokaisessa iteraatiossa, ts. Jokaisen iteraation aikana uusi työkohde lisätään etusijalla.
• Ensin priorisoidut työt otetaan huomioon. Lisätyt työkohteet voidaan priorisoida tai poistaa esineiden pinosta milloin tahansa.
• Ryhmä keskustelee siitä, miten he aikovat toteuttaa kunkin vaatimuksen. Mallinnusta käytetään tähän tarkoitukseen.
• Mallinnusanalyysi ja suunnittelu tehdään jokaiselle vaatimukselle, joka aiotaan toteuttaa kyseiselle iteraatiolle.

3. Malli myrsky:

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

• Tässä mallinnusistunnossa on mukana 2/3-jäseninen ryhmä, joka keskustelee asioista paperilla tai taululla.
• Yksi tiimin jäsen pyytää toista mallintamaan heidän kanssaan. Tämä mallinnusistunto kestää noin 5-10 minuuttia. Missä tiimin jäsenet kokoontuvat jakamaan taulua / paperia.
• He tutkivat asioita, kunnes eivät löydä ongelman pääasiallista syytä. Juuri ajoissa, jos yksi tiimin jäsen tunnistaa ongelman, jonka hän haluaa ratkaista, hän ottaa nopeasti apua muille tiimin jäsenille.
• Muut ryhmän jäsenet tutkivat sitten asiaa ja sitten kaikki jatkavat kuten aiemmin. Sitä kutsutaan myös stand-up-mallinnukseksi tai asiakkaiden QA-istunnoiksi.

4. Testiohjattu kehitys (TDD).

• Se edistää hakukoodisi ja yksityiskohtaisten eritelmien vahvistamista.
• Sekä hyväksymistesti (yksityiskohtaiset vaatimukset) että kehittäjien testit (yksikkötesti) ovat TDD: n tuloja.
• TDD tekee koodista yksinkertaisemman ja selkeämmän. Sen avulla kehittäjä voi ylläpitää vähemmän dokumentaatiota.

5. Arvostelut.

• Tämä on valinnainen. Se sisältää kooditarkastukset ja malliarvostelut.
• Tämä voidaan tehdä jokaiselle iteraatiolle tai koko projektille.
• Tämä on hyvä vaihtoehto antaa palautetta projektille.

Test Driven Development (TDD) vs. Ketterä malliohjattu kehitys (AMDD)

TDD	AMDD
TDD lyhentää ohjelmoinnin palautesilmukkaa	AMDD lyhentää mallinnuspalautesilmukkaa.
TDD on yksityiskohtainen erittely	AMDD toimii isommissa asioissa
TDD edistää laadukkaiden koodien kehittämistä	AMDD edistää korkealaatuista viestintää sidosryhmien ja kehittäjien kanssa.
TDD puhuu ohjelmoijille	AMDD keskustelee yritysanalyytikoiden, sidosryhmien ja data-ammattilaisten kanssa.
TDD ei visuaalisesti suuntautunut	AMDD visuaalisesti suuntautunut
TDD: llä on rajoitettu soveltamisala ohjelmistotöihin	AMDD: llä on laaja soveltamisala, mukaan lukien sidosryhmät. Siihen kuuluu pyrkimys yhteisymmärrykseen
Molemmat tukevat evoluutiokehitystä	--------------------------------------------

Esimerkki TDD: stä

Tässä tässä esimerkissä määritämme luokan salasanan. Tämän luokan osalta yritämme täyttää seuraavat ehdot.

Salasanan hyväksymisen ehto:

• Salasanan tulisi olla 5-10 merkkiä.

Ensin kirjoitetaan koodi, joka täyttää kaikki yllä olevat vaatimukset.

Skenaario 1 : Testin suorittamiseksi luomme luokan PasswordValidator ();

Suoritetaan luokan TestPassword () yläpuolella;

Lähtö ohitetaan alla olevan kuvan mukaisesti;

Tuotos :

Skenaario 2 : Tässä voidaan nähdä, että menetelmässä TestPasswordLength () ei tarvitse luoda luokan PasswordValidator -ilmentymää. Esimerkki tarkoittaa luokan objektin luomista viittaamaan kyseisen luokan jäseniin (muuttujat / menetelmät).

Poistamme luokan PasswordValidator pv = new PasswordValidator () koodista. Voimme kutsua isValid () -menetelmää suoraan PasswordValidatorilla. IsValid ("Abc123") . (Katso alla oleva kuva)

Joten me Refactor (vaihda koodi) kuten alla:

Skenaario 3 : Kun tulos on korjattu uudelleen, sen tila on epäonnistunut (katso alla oleva kuva), koska olemme poistaneet ilmentymän. Joten ei ole viittausta ei- staattiseen menetelmään isValid ().

Joten meidän on muutettava tätä menetelmää lisäämällä "staattinen" sana ennen loogista, koska julkinen staattinen looginen isole on isvalid (merkkijonon salasana). Refactoring Class PasswordValidator () poistaa yllä olevan virheen testin läpäisemiseksi.

Tuotos:

Muutosten jälkeen luokassa PassValidator (), jos suoritamme testin, lähtö ohitetaan alla olevan kuvan mukaisesti.

TDD: n edut

• Varhainen virheilmoitus.

  Kehittäjät testaavat koodinsa, mutta tietokantamaailmassa tämä koostuu usein manuaalisista testeistä tai kertaluonteisista skripteistä. TDD: n avulla muodostat ajan myötä joukon automaattisia testejä, jotka sinä ja kaikki muut kehittäjät voivat suorittaa uudelleen haluamallasi tavalla.

• Parempi suunnittelu, puhtaampi ja laajennettavissa oleva koodi.
  • Se auttaa ymmärtämään, miten koodia käytetään ja miten se on vuorovaikutuksessa muiden moduulien kanssa.
  • Se antaa paremman suunnittelupäätöksen ja ylläpidettävämmän koodin.
  • TDD: n avulla voidaan kirjoittaa pienempi koodi, jolla on yksi vastuu, eikä monoliittisia menettelyjä, joilla on useita vastuita. Tämä helpottaa koodin ymmärtämistä.
  • TDD pakottaa myös kirjoittamaan vain tuotantokoodin läpäisemään testit käyttäjän vaatimusten perusteella.
• Luottamus refraktorille
  • Jos koodaat refaktorin, koodissa voi olla katkeamisen mahdollisuuksia. Joten automaattisten testien avulla voit korjata nämä tauot ennen julkaisua. Asianmukainen varoitus annetaan, jos automaattisia testejä käytettäessä havaitaan taukoja.
  • TDD: n käyttämisen pitäisi johtaa nopeampaan, laajennettavissa olevaan koodiin, jossa on vähemmän vikoja, jotka voidaan päivittää minimaalisilla riskeillä.
• Hyvä ryhmätyöhön

  Tiimin jäsenen poissa ollessa muut ryhmän jäsenet voivat helposti noutaa koodin ja työskennellä sen parissa. Se auttaa myös tiedon jakamista, mikä tekee tiimistä tehokkaamman kokonaisuutena.

• 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 testiohjattua kehitystä. Se on prosessi koodin muokkaamiseksi aiemmin suunnitellun testin läpäisemiseksi.
• Se painottaa enemmän tuotantokoodia kuin testitapausten suunnittelua.
• Testiohjattu kehitys on prosessi koodin muokkaamiseksi aiemmin suunnitellun testin läpäisemiseksi.
• Ohjelmistotuotannossa se tunnetaan joskus nimellä "Test First Development".
• TDD sisältää koodin muokkaamisen eli jonkin määrän koodin muuttamisen / lisäämisen olemassa olevaan koodiin vaikuttamatta koodin käyttäytymiseen.
• TDD käytettäessä koodi tulee selkeämmäksi ja helpommin ymmärrettäväksi.

Tämän artikkelin on kirjoittanut Kanchan Kulkarni