BDD (lyhennetty englannin sanoista Behavior-driven development , kirjaimellisesti " kehitys käyttäytymisen kautta ") on ohjelmistokehitysmetodologia, joka on TDD ( test -driven development) -metodologian sivuhaara.
Tämän metodologian pääideana on puhtaasti teknisten ja liiketoiminnallisten etujen yhdistäminen kehitysprosessissa, jolloin johtohenkilöstö ja ohjelmoijat voivat puhua samaa kieltä. Näiden henkilöstöryhmien välisessä viestinnässä käytetään toimialuekohtaista kieltä , joka perustuu ei-asiantuntijan ymmärrettäviin luonnolliseen kielen konstrukteihin, jotka yleensä ilmaisevat ohjelmistotuotteen käyttäytymistä ja odotettuja tuloksia.
Tämän lähestymistavan uskotaan olevan tehokas, kun aihealue, jolla ohjelmistotuote toimii, on kuvattu hyvin monimutkaisesti.
BDD-metodologia on TDD:n laajennus siinä mielessä, että ennen testin kirjoittamista on ensin kuvattava lisätyn toiminnon haluttu tulos verkkoaluekohtaisella kielellä. Tämän jälkeen asiantuntijat tai erikoisohjelmistot kääntävät tämän kielen rakenteet testikuvaukseksi.
BDD keskittyy seuraaviin kysymyksiin:
Näiden kysymysten perusteella BDD edellyttää testinimien olevan kokonaisia lauseita, jotka alkavat verbillä subjunktiivissa ja seuraavat liiketoiminnan tavoitteita. Hyväksymistestikuvaukset tulee kirjoittaa joustavalla käyttäjätarinakielellä, esim.
[Henkilönä, jonka liiketoiminnallisia etuja palvellaan] haluan [kuvailla toiminnallisuutta tavalla, jolla sen pitäisi toimia] voidakseni [kuvailla etua].
Hyväksymiskriteerit tulee kuvata skenaariolla, jonka käyttäjä toteuttaa tuloksen saavuttamiseksi.
Kuten jo todettiin, ohjelmiston testit on kuvattava ohjelmoitavan laitteen halutun toiminnan kannalta. Toivotulla käyttäytymisellä tarkoitetaan tässä sellaista, jolla on arvoa yritykselle. Halutun käyttäytymisen kuvaus annetaan käyttäytymismäärittelyn avulla .
Käyttäytymisspesifikaatio on rakennettu puolimuodolliseen muotoon. Tällä hetkellä BDD:n käytännössä on luotu seuraava rakenne:
BDD ei tarjoa muodollisia sääntöjä, mutta vaatii, että käytetään rajoitettua vakiolauseiden joukkoa, joka sisältää kaikki käyttäytymismäärityksen elementit. Vuonna 2007 Dan North ehdotti määritysmallia, joka sai suosiota ja tuli tunnetuksi kurkkukielenä [1] [2] .
Kurkkukielen peruslausekkeet on esitetty seuraavassa taulukossa.
| Avainsana englanniksi | Venäjän kielen sovitus | Kuvaus |
|---|---|---|
| Tarina ( Ominaisuus [3] ) |
Tarina | Jokainen uusi määrittely alkaa tällä avainsanalla, jota seuraa kaksoispiste tarinan nimen subjunktiivimuodossa. |
| Kuten a | Miten (roolissa) | Sen henkilön rooli liiketoimintamallissa, joka on kiinnostunut tästä toiminnasta. |
| Jotta | Saavuttaa | Lyhyesti, mitkä ovat henkilön tavoitteet. |
| Haluan | Haluan | Kuvaile lyhyesti lopputulosta. |
| Skenaario | Skenaario | Jokainen tarinan skenaario alkaa tällä sanalla, jonka jälkeen skenaarion tavoite kirjoitetaan subjunktiivimuodossa kaksoispisteellä erotettuna. Jos yhdessä tarinassa on useita skenaarioita, niin avainsanan jälkeen tulee kirjoittaa sen järjestysnumero. |
| Annettu | Annettu | Alkukunnossa. Jos alkuehtoja on useita, jokainen uusi ehto lisätään uudelta riviltä käyttämällä And-avainsanaa. |
| Kun | Kun ( huom : jotain tapahtuu) | Tapahtuma, joka käynnistää tämän skriptin. Jos tapahtumaa ei voida paljastaa yhdellä lauseella, kaikki myöhemmät yksityiskohdat paljastuvat Ja- ja Mutta-avainsanojen kautta. |
| Sitten | Sitten | Tulos, joka käyttäjän tulee lopulta havaita. Jos tulosta ei voida paljastaa yhdellä lauseella, kaikki myöhemmät yksityiskohdat paljastuvat Ja- ja Mutta-avainsanojen kautta. |
| Ja | Ja | Apuavainsana, konjunktion analogi . |
| Mutta | Mutta | Apuavainsana, negatiivisen analogi . |
Seuraava esimerkki havainnollistaa käyttäytymismäärittelyä Gherkin-kielellä.
| Tarina: Palautukset menevät varastoon Myymälän omistajana Pysyäkseni varastossa haluan lisätä tuotteet takaisin varastoon, kun ne palautetaan. Skenaario 1 : Hyvitetyt tuotteet tulee palauttaa varastoon. Koska asiakas on aiemmin ostanut minulta mustan villapaidan ja minulla on varastossa kolme mustaa villapaitaa. Kun he palauttavat mustan puseron hyvitystä vastaan, minulla pitäisi olla neljä mustaa villapaitaa varastossa. Skenaario 2 : Korvatut tuotteet tulee palauttaa varastoon Koska asiakas on aiemmin ostanut minulta sinisen vaatteen Ja minulla on kaksi sinistä vaatetta varastossa ja kolme mustaa vaatetta varastossa. Kun he palauttavat sinisen vaatteen vaihtoa varten mustana, minulla pitäisi olla kolme sinistä vaatetta varastossa ja kaksi mustaa vaatetta varastossa. | Historia: Palautettu tuote on säilytettävä varastossa Myymälän omistajana Pysyäkseni kirjaa varaston varastosta haluan palauttaa tietueet varastoon palautetuista tuotteista. Skenaario 1 : Palautettavat tuotteet tulee laittaa varastoon Koska asiakas on aiemmin ostanut minulta mustan villapaidan JA minulla on jo kolme samanlaista varastossa. Kun asiakas palauttaa ostaman neuleen Sitten minun pitäisi nähdä, että varastossa on nyt 4 mustaa villapaitaa. Skenaario 2 : Vaihdetut tuotteet on palautettava varastoon Ottaen huomioon, että asiakas osti minulta sinisen vaatteen JA minulla on varastossani kaksi näistä tuotteista sinisenä JA kolme mustaa tuotetta. Kun asiakas palauttaa sinisen vaatteen korvattavaksi samanlaisella, mutta mustalla , minun pitäisi nähdä, että varastossa on nyt kolme tuotetta siniselle vaatteelle JA kaksi tuotetta mustalle. |
Puolimuodollinen käyttäytymismäärittelymuoto edellyttää rajoitetun joukon ehdotuksia, joista johdon ja kehittäjien on sovittava etukäteen. Tämän perusteella rakennetaan puitteet BDD:n tukemiseksi seuraavien periaatteiden mukaisesti:
Frameworks, kuten JBehave ja RBehave, jotka perustuvat Gherkin-kieleen, on rakennettu tälle periaatteelle. Jotkut puitteet on rakennettu samalla tavalla, kuten CBehave ja Cucumber.
Oletetaan, että kehitämme moottoria pelille "Life" ja meidän on lisättävä kyky aluksi sijoittaa eläviä soluja kentälle. Oletetaan, että kun käyttäjä valitsee jonkin kentän vapaan pisteen, siihen ilmestyy elävä solu. Jos käyttäjä valitsee kenttäpisteen, jossa solu on jo käytössä, solu katoaa ja kenttäpiste vapautuu. Kentän koordinaatit syötetään muodossa (x,y), jossa x on vaakapisteen numero ja y on pystypisteen numero. Molempien koordinaattien vertailupiste alkaa vasemmasta yläkulmasta, yhdestä.
Jättäen pois käyttäytymismäärittelyn kuvauksen yksinkertaisuuden vuoksi voimme kirjoittaa tällaisen skriptin Gherkinissä.
Annettu 5 x 5 - peli Kun vaihdan solua kohdassa ( 3 , 4 ) Silloin ruudukon pitäisi näyttää tältä ..... ..... ..... ..X.. ..... Kun minä Vaihda solua kohdassa ( 3 , 5 ) Sitten ruudukon pitäisi näyttää tältä ..... ..... ..... ..X... ..X.. Kun vaihdan solua kohdassa ( 3 , 4 ) ) Silloin ruudukon pitäisi näyttää tältä ..... ..... ..... ..... ..X..JBehave-kehys on kirjoitettu Java-kielellä, joten testit käännetään Java-koodiksi. JBehave-kehyksessä tämä komentosarja välitetään pelkkänä tekstitiedostona, joka luetaan rivi riviltä. Kehittäjä tarvitsee vain toimintoja, joita JBehaven pitäisi kutsua, kun se siirtyy seuraavalle riville. Esimerkiksi testitoteutus voi näyttää tältä:
yksityinen pelipeli ; _ yksityinen StringRenderer ; _ @Given ( "$leveys $korkeus peli" ) public void theGameIsRunning ( int leveys , int korkeus ) { game = new Game ( leveys , korkeus ); renderer = uusi StringRenderer (); peli . setObserver ( renderöijä ); } @When ( "Vaihdan solua osoitteessa ($sarake, $rivi)" ) public void iToggleTheCellAt ( int sarake , int rivi ) { peli . toggleCellAt ( sarake , rivi ); } @Sitten ( "ruudukon pitäisi näyttää $grid" ) public void theGridShouldLookLike ( String grid ) { assertThat ( renderer . asString (), equalTo ( grid )); }Funktion kohdistamiseksi yksiselitteisesti Gherkin-ehdotukseen käytetään Java-merkintöjä, jotka JBehave-kehys tarjoaa. Esimerkiksi kun moottorin jäsentäjä saavuttaa minkä tahansa lauseen, kuten
Kun vaihdan solua kohdassa (n, n)JBehave-moottori laskee huomautuksesta, että menetelmää on kutsuttava
void iToggleTheCellAt ( int sarake , int rivi )lisäksi annotaatio on kirjoitettu siten, että moottori "ymmärtää", että jotkin lauseen osat on kaapattava ja siirrettävä funktiolle syötteenä (tässä esimerkissä nämä ovat kenttäpisteen koordinaatit). Seuraavaksi toiminto kutsuu itse "Life" -pelin toimintoja, ja kehittäjä tarkistaa pelimoottorin käyttäytymisen tavallisilla TDD-työkaluilla.
C/C++
|
Java
|