Test-Driven Development (TDD) on tuttu useimmille kehittäjille. Acceptance Test-Driven Development (ATDD) painottuu prosessissa enemmän liiketoimintavaatimuksiin, eikä se välttämättä ole yhtä tuttu. Molemmat tekniikat mahdollistavat lyhyemmät kehityssyklit. Tämä käytännönläheinen opastus näyttää, miksi ja miten.
Tatu Kairi
Principal Consultant
Tatu enjoys piña coladas, getting caught in the rain, is not into yoga and has half a brain.
DevOps-alalla jo jonkin aikaa työskennelleenä minulle juuri näkemäni muutosmatkat tekevät tästä työstä merkityksellistä.
Olen nähnyt, miten siirtyminen yhteistyöhön perustuviin toimintatapoihin ja monialaisten käytäntöjen hyödyntäminen kulkevat käsi kädessä: kehittäjät voivat laajentaa osaamistaan monipuolisemmaksi. Tämä edistää eri erikoisalojen välistä ymmärrystä, jolloin lopullinen tavoite – tyytyväinen asiakas – saavutetaan paremmin ja nopeammin.
Test-Driven Development (TDD) on useimpien kehittäjien perusmenetelmä, kun taas Acceptance Test-Driven Development (ATDD) painottuu enemmän prosessin liiketoimintavaatimuksiin eikä välttämättä ole kehittäjille yhtä tuttu. Molemmat menetelmät lyhentävät kuitenkin kehityssyklejä ja nostavat asiakkaan tarpeet projektityön keskiöön.
Vaikka sekä TDD että ATDD ovat laajasti käytössä alalla, niiden koko potentiaalia ei hyödynnetä. Tässä opetan, miten saat käyttöösi kaikki vielä hyödyntämättömät mahdollisuudet.
Perusteisiin palaaminen: Shifting left
Jokainen ohjelmisto käy elinkaarensa aikana läpi seuraavat vaiheet:
Ensin joku saa idean, joka ratkaisee ongelman tai mahdollistaa jotain aiemmin saavuttamatonta. Ideasta syntyy vaatimuksia, joiden toteutus suunnitellaan niin teknisesti kuin taloudellisesti. Sen jälkeen toteutus tehdään. Seuraavaksi ratkaisun laatu on arvioitava. On varmistettava, että ohjelmisto toimii teknisesti suunnitellulla tavalla, sekä validoitava, että se täyttää määrittelynsä. Lopuksi ohjelmistoa on ylläpidettävä niin kauan, kunnes se poistetaan käytöstä.
Muista: nämä vaiheet ovat muuttumattomia. Ohjelmistokehityksessä mitään vaihetta ei voi ohittaa, vaan jokaiseen on puututtava jossain vaiheessa. Puuttuvat vaatimukset tai laiminlyöty ylläpito tarkoittavat vain, että vaihe on hoidettu erittäin huonosti – mutta siihen on silti puututtu.
Agilen ja DevOpsin tavoitteena ei ole kiertää työtä, vaan tehdä sitä rinnakkain älykkäiden työtapojen ja automaation avulla – tätä kutsutaan shifting leftiksi.
Kun ensimmäinen vaatimus laaditaan, siirrymme heti sen suunnitteluun, toteutukseen, testaukseen ja julkaisuun loppukäyttäjille. Samaan aikaan muita vaatimuksia luodaan, suunnitellaan, toteutetaan, testataan ja julkaistaan rinnakkain. Haluamme aloittaa ominaisuuden jokaisen vaiheen mahdollisimman aikaisin. Toisin sanoen Agile ja DevOps pyrkivät siirtämään mahdollisimman paljon työtä vasemmalle.
Test-Driven Development (TDD)
Yksi tapa toteuttaa “shifting leftiä” on käyttää Test-Driven Developmentiä (TDD). Menetelmä ”keksittiin” alun perin 2000-luvun alussa, ja siitä on sittemmin tullut olennainen osa hyvän kehittäjän työkalupakkia. Sen suurin hyöty on, että osa testaustyöstä – tekninen yksikkötestaus – tehdään rinnakkain itse toteutuksen kanssa. Tämä on erinomaista, sillä koodi ja sitä varmentavat testit valmistuvat käsi kädessä, mikä ohjaa kehittäjiä korkeampiin laatustandardeihin.
Shifting left ei ainoastaan mahdollistanut työn tekemistä rinnakkain, vaan loi myös täysin uuden tavan käyttää testausta toteutettavan koodin suunnittelutyökaluna. Työn siirtämisen vasemmalle lisäksi tämä tuottaa alusta alkaen laadukkaampaa koodia.
Katsotaan pientä Pythonilla kirjoitettua esimerkkiä siitä, miten asioita tehtiin ennen TDD:tä.
Tarvitsemme Thingamabobin, joka vastaanottaa verkon kautta todennettuja yhteyksiä, jotta sillä voidaan tehdä asioita. Tämän yksinkertaisen määrittelyn perusteella voisimme luoda jotain yllä olevan kaltaista.
Ja tietenkin luomme sille myös vastaavan yksikkötestin.
Hyvä, eikö? TDD:n avulla voimme varmistaa, ettemme koskaan ”unohda” luoda myös testitapausta. Katsotaan kuitenkin, mitä tapahtuu, kun aloitamme kirjoittamalla vain testitapauksen.
Tarvitsen Thingamabobin, jolla voin tehdä asioita.
Siinä! Mitä voin seuraavaksi toteuttaa, jotta testi menee läpi...
Näyttää siltä, että minun on jäsenneltävä koodini niin, että yhteys muodostetaan taustalla sujuvasti. Tiedänpä: käytän tähän Pythonin context managereita!
Tässä esimerkissä loimme Thingamabobille huomattavasti miellyttävämmän käyttöliittymän, jossa loppukäyttäjän – kutsuvan koodin – ei tarvitse huolehtia yhteyden hallinnasta. Jälkimmäinen toteutus vaatii vähemmän toteutettavia rivejä ja on myös kestävämpi tulevaisuudessa: jos yhteys muuttuu jollain tavalla, testitapaus ei rikkoudu, sillä sen tehtävä on vain varmistaa ”asioiden tekeminen”. Ensimmäinen esimerkki voi vaikuttaa yksinkertaisemmalta, mutta sitä se ei ole. Testitapaus ohjasi suunnitteluratkaisujamme kohti parempaa koodia.
Acceptance Test-Driven Development (ATDD)
TDD on periaate, joka paransi koodin toteutusta yhdistämällä teknisen testauksen toteutukseen. Näin se mahdollisti työn rinnakkaistamisen, mutta paljasti myös täysin uuden ja odottamattoman tavan työskennellä.
Hyväksymistestauksella on monia nimiä, kuten User Acceptance Testing (UAT), päästä päähän -testaus, Alpha-testaus ja Beta-testaus. Nykyään uudet testiautomaatiotyökalut ovat mahdollistaneet tämän testauksen osa-alueen automatisoinnin. Aiemmin se voitiin aloittaa vasta, kun suurin osa tai kaikki toteutustyö oli valmis. Avoimen lähdekoodin työkaluilla, kuten Robot Frameworkilla tai Cucumberilla, voimme automatisoida loppukäyttäjän vuorovaikutuksen sovelluksessamme manuaalisen työn sijaan.
Saatat pohtia, miksi manuaalisen testauksen automatisointiin vahvasti keskittyvä käytäntö esitellään TDD:n kaltaisen, verrattain teknisen käytännön rinnalla. Vakuutan, ettei syynä ole vain se, että nimet kuulostavat samankaltaisilta. ATDD mahdollistaa myös aiemmin myöhemmin tehtävän työn ”siirtämisen vasemmalle”.
Testauksen tämän viimeisen vaiheen automatisointi poistaa ihmisiltä manuaalisen työn, mikä on yksi DevOpsin keskeisistä periaatteista. Kuten TDD:ssä, voimme siirtyä vasemmalle entistä enemmän hyödyntämällä Acceptance Test-Driven Developmentia (ATDD), jossa aloitamme testitapausten kirjoittamisen paljon aiemmin kuin ennen: jo vaatimuksia kerättäessä.
ATDD:n ytimessä on toinen pitkään käytetty käytäntö: käyttäjätarinat. Niiden avulla määrittelemme vaatimukset epämuodollisella, luonnollista kieltä käyttävällä kuvauksella kuvitellun loppukäyttäjän näkökulmasta.
Aiemmin ohjelmistokehitys saattoi näyttää suunnilleen tältä:
Kirjoita vaatimusmäärittely dokumenttiin
Käytä aikaa dokumentin ymmärtämiseen ja suunnittele toteutus lukuisten keskustelujen jälkeen epämääräisen käsityksen pohjalta siitä, mitä halutaan
...toteuta ominaisuus koodina...
Käytä vielä enemmän aikaa sen selvittämiseen, toimiiko toteutus tarkoitetulla tavalla ja täyttääkö se alkuperäisen vaatimuksen…
Palaa (yleensä) toteuttamaan ominaisuus eri tavalla, kun käytettävissä on enemmän tietoa
Uutta tietoa ilmenee: toista vaiheet 3–5 yhä uudelleen.
Acceptance Test-Driven Developmentin (ATDD) työnkulku näyttää nyt tältä:
Kirjoita määrittely yhtenäisessä muodossa testitapauksiksi, kunnes kaikki ymmärtävät ominaisuuden.
Toteuta ominaisuus ja automatisoi samalla testitapaus.
Jos ilmenee muutosta edellyttävää uutta tietoa, toista vaihe 1 ja jatka.
Varmista lopputulos suorittamalla testitapaus. Valmista.
Esimerkki on tehty Robot Frameworkilla
Käyttäjätarinamuodon hyödyt eivät rajoitu siihen, että ymmärrämme ongelman paremmin. Keskustelu ominaisuudesta myös keskittyy loppukäyttäjän näkökulmaan, mikä puolestaan pakottaa kaikki osallistujat – liiketoiminnan, suunnittelun, kehittäjät, testaajat ja operoinnin – tarkastelemaan kokonaisuutta ja sitä, miksi työtä ylipäätään tehdään.
Kun kaikki ymmärtävät, mistä on kyse, testitapauksesta tulee seurattava kokonaisuus elinkaaren kaikissa muissa vaiheissa. Se versioidaan koodin kanssa versionhallintajärjestelmässä, toimii liiketoimintavaatimuksen elävänä dokumentaationa ja voidaan aina suorittaa, mikä todistaa ominaisuuden toimivan.
TDD + ATDD
Olen näyttänyt, miten TDD:n avulla tehtävä tekninen yksikkötestaus nostaa testitapaukset koodin suunnittelutyökaluksi. Samoin ATDD ei ainoastaan mahdollista pitkälti manuaalisen testausvaiheen automatisointia, vaan nostaa sen vaatimusten määrittelyn ytimeen.
Suunnitteletko siis yksinkertaisempaa koodia TDD:n avulla? Onko yhteistyö liiketoiminnan ja kehityksen kanssa helpottunut ATDD:n ansiosta? Kerro ajatuksistasi tai ehdota tulevia aiheita, joista voisin kirjoittaa yhteydenottosivullamme.
Tutustu koulutuskokonaisuuteen.
- DevOps
- CI/CD
Subscribe to our newsletter
Related blogs
