Mitä ovat TDD ja ATDD?

Tässä artikkelissa tuomme esiin samankaltaisuuksia ja eroja kahden suositun testausmenetelmän välillä, jotka tunnetaan yleisesti TDD:nä ja ATDD:nä.

TDD tarkoittaa testilähtöistä kehitystä, kun taas ATDD tarkoittaa hyväksymistestilähtöistä kehitystä. Ymmärrys siitä, miten nämä kaksi testausmenetelmää toimivat, on kriittisen tärkeää testauksen ammattilaisille, ja tämä viesti on alkuopas, jonka avulla pääset alkuun molempiin tutustuessasi. Ymmärrät TDD:n vs. ATDD:n.

Mitä on testivetoinen kehitys (TDD)?

TDD on järjestelmä, jolla ohjelmistoja kehitetään Extreme Programming (XP) -periaatteiden mukaisesti, mutta ajan mittaan se on kuitenkin versonut itsenäiseksi ohjelmistokehitystekniikaksi.

TDD:ssä yksikkötestausta tehdään suoraan lähdekoodiin.

Ensiksi testaaja kirjoittaa automatisoidun testitapauksen, joka määrittelee halutun toiminnon, joka järjestelmän tulisi ideaalitilanteessa suorittaa, mutta suunnittelee testitapauksen tarkoituksella siten, että järjestelmä ei voi täyttää sitä nykytilassaan.

Toiseksi kehittäjä tekee muistiinpanot syistä, joiden vuoksi järjestelmä ei täyttänyt testiä, ja kirjoittaa koodin, jota tarvitaan järjestelmän refaktoroimiseksi niin, että se läpäisee testin toisella yrittämällä. Tämä prosessi on tiivistetty alla olevaan grafiikkaan.

TDD-prosessi jatkuu tällä tavalla, siksakkia epäonnistumisen ja onnistumisen välillä siten, että jokainen iteraatio ajaa järjestelmän äärirajoilleen ja auttaa sitä sitten voittamaan ne syntyvän palautteen avulla.

TDD on kokeilu vapaaehtoisessa epäonnistumisessa, ja vaatii melkoista rohkeutta, jotta voi kietoa päänsä tähän vastoin intuitiiviseen tekniikkaan. Kun kuitenkin onnistut, sinut palkitaan yksinkertaisella mutta erittäin tehokkaalla menetelmällä, jolla voit torjua epäonnistumisen pelkoa testauksen aikana ja samalla parantaa tekemääsi työtä.

Mitä on hyväksymistestauslähtöinen kehitys (Acceptance Test-Driven Development, ATDD)?

ATDD on testauksen yhteistoiminnallinen menetelmä, joka pakottaa kaikki uuden ohjelmiston luomiseen osallistuvat henkilöt (esim.esim. testaajat, kehittäjät ja käyttäjät) määrittelemään tiiminä hyväksymiskriteerit, jotka järjestelmän on täytettävä kehityksen alkuvaiheessa.

Tässä vaiheessa tarkoituksena on varmistaa, että kaikki nämä sidosryhmät ovat yhtä mieltä projektin päätavoitteista, erityisesti loppukäyttäjän odottaman toiminnallisuuden osalta. ATDD:n tämän vaiheen aikana tekniikat, kuten käyttäjäpersoonat ja käyttäjätarinat, voivat olla erittäin hyödyllisiä.

Kun hyväksymistestit lopulta ajetaan järjestelmälle, havaitaan epäonnistumiset, ja kehittäjät refaktoroivat vialliset komponentit kirjoittamalla koodia, jota tarvitaan hyväksymiskriteerien täyttämiseksi seuraavalla yrittämällä.

Tämä prosessi suoritetaan iteratiivisesti, yleensä jokaisen sprintin lopussa, kunnes lopullinen tuote on valmis käyttöönottoa varten. Alla oleva kaavio selittää tämän.

ATDD antaa tiimille selkeämmän näkemyksen siitä, miten lopputuote toimii, jolloin kaikki voivat keskittyä pitkän aikavälin tavoitteisiin sen sijaan, että eksyisivät yksittäisiin koodiriveihin.

Yhteenvetona

Nyt sinulla on hyvä käsitys TDD:n ja ATDD:n välisistä peruseroista. Nämä kaksi testausmenetelmää liittyvät läheisesti toisiinsa, mutta ATDD sisältää prosessiin myös hyväksymistestauksen ja painottaa tiimin yhteistyötä enemmän kuin TDD.

Kummatkin lähestymistavat sopivat hyvin yhteen ketterien periaatteiden kanssa, sillä molemmat kannustavat palautteen keräämiseen aiempien virheiden pohjalta. Kun jatkuvasti muokkaat järjestelmää ja puutut edellisessä yrityksessä kohtaamiisi ongelmiin, nämä menetelmät auttavat sinua kehittämään arvokkaamman lopputuotteen inkrementaalisesti.

Liity 60,000+ tilaajan joukkoon

Saa viimeisimmät blogit, toimialapäivitykset ja eksklusiiviset vinkit.

*Sähköpostiosoitteesi on turvassa kanssamme, vihaamme myös roskapostia.