TDD vs BDD

Test Driven Development (TDD) on ohjelmointitapa, joka korostaa testien kirjoittamista ennen koodifunktion kehittämistä. Tämä menetelmä varmistaa, että koodi täyttää tarkoitetut vaatimukset ja auttaa estämään virheitä.

📚 Alkuperä

Test Driven Development (TDD) kehitettiin Kent Beckin toimesta 1990-luvun lopulla osana Extreme Programmingia.

TDD noudattaa sykliä, jossa lisätään testi, testin suoritus epäonnistuu, kirjoitetaan koodia testin läpäisemiseksi ja sitten koodia refaktoroidaan.

TDD keskittyy kerrallaan pienten koodiyksiköiden testaamiseen, varmistaen, että järjestelmä rakennetaan inkrementaalisesti ja korkealla testikattavuudella.

Tunnetaan myös 'Red-Green-Refactor' -syklinä, jossa koodia kirjoitetaan epäonnistuneen testin läpäisemiseksi ja sitten refaktoroidaan parantamaan sen rakennetta.

Behavior Driven Development (BDD) on ohjelmistokehitysprosessi, jonka tavoitteena on parantaa yhteistyötä. Se keskittyy määrittelemään järjestelmän toimintaa käyttäjän näkökulmasta, käyttäen luonnollisella kielellä kirjoitettuja spesifikaatioita.

BDD kehittyi Test Driven Development (TDD) -menetelmästä, mutta se on käyttäjälähtöisempi vaatimuksien ja järjestelmän toiminnan suhteen. Tämä lähestymistapa auttaa varmistamaan, että ohjelmistokehitys on paremmin linjassa loppukäyttäjän odotusten ja tarpeiden kanssa.

Siirtyminen TDD:stä BDD:hen on luonteenomaista siirtymiselle testaamisesta, joka perustuu pelkästään koodiin, testaamiseen, joka perustuu järjestelmän toimintaan käyttäjän näkökulmasta. Tämä mahdollistaa syvemmän ymmärryksen käyttäjän tarpeista ja siitä, miten järjestelmän tulisi toimia niitä täyttääkseen.

BDD käyttää Gherkin-kieltä spesifikaatioiden kirjoittamiseen tavalla, joka on ymmärrettävä sekä teknisille että ei-teknisille tiimin jäsenille. Tämä mahdollistaa spesifikaatioiden toimimisen yhteisenä totuuden lähteenä, parantaen kommunikaatiota ja vähentäen väärinymmärryksiä.

BDD edistää yhteistä ymmärrystä odotetusta ohjelmistokäyttäytymisestä, varmistaen, että kaikki osapuolet, mukaan lukien ei-tekniset sidosryhmät, ymmärtävät projektin tavoitteet selkeästi. Tämä lähestymistapa auttaa välttämään ristiriitoja liiketoiminnan tarpeiden ja kehitystiimin toimittaman välillä.