TDD ja ATDD Niklas Collin Naulakatu 3, 33100 Tampere www.kilosoft.fi
Kilosoft Kilosoft on ohjelmistokehityksen, laadunvarmistuksen ja verkonhallintajärjestelmien asiantuntijayritys. Kilosoft Oy on perustettu vuonna 2002 Toimipaikkamme sijaitsevat Tampereella, Espoossa ja Jyväskylässä Toimimme myös kansainvälisesti yhteistyökumppaneidemme kautta Olemme kannattava kasvuyritys Palveluksessamme on vuoden 2010 syyskuussa noin 70 ohjelmistotuotannon ammattilaista Liikevaihtomme vuonna 2009 oli 2,1 M. Ennusteemme vuodelle 2010 on 3,7 4 M
Luennoija Niklas Collin Ohjelmistoarkkitehti Kilosoftilla Siirtyi Kilosoftin palvelukseen 2010 alkuvuodesta Novaloc Oy:n liiketoiminnan myynnin myötä Myydyn Novaloc Oy:n osaperustaja TTY:n kasvatteja Tutkintouudistus painosti valmistumaan alkuvuodesta :) Menossa Australiaan APSEC 2010:een puhumaan TDD:stä ja CI:stä yhdessä prof. Tommi Mikkosen kanssa loppuvuodesta
Agenda 1) Motivaatio ja käytettyä sanastoa 2) Testiohjattu kehitys (TDD) 3) Hyväksymistestivetoinen kehitys (ATDD)
Olen koodari! Minäkö muka testaisin? Nykyaikaiseen ohjelmistokehitykseen kuuluu oleellisesti automatisoitu testaaminen Valtaosa automatisoiduista testeistä jää yleensä kehittäjien harteille Varsinaiset testaajat keskittyvät käyttöliittymän testaamiseen, suorituskykytesteihin, toiminnallisuuden vertaamiseen määrittelyä vasten jne On siis oleellista osata kirjoittaa hyviä automatisoituja testejä jos aikoo tehdä ohjelmointityötä työkseen nykyaikana Jos osaat kirjoittaa hyviä automatisoituja testejä, niin työpaikan saaminen on kokolailla varmaa
Hieman testaussanastoa Sekaannuksien välttämiseksi kerrataan testaussanastoa Yksikkötesti On yleistä, että kaikkea automatisoituja testejä kutsutaan yksikkötesteiksi Tämä EI pidä paikkaansa! Keskustellessa uuden henkilön kanssa testauksesta on hyvä aina varmistaa, että puhutte samoilla termeillä Testi, joka testaa yhtä koodiyksikköä, kuten esimerkiksi luokkaa Integraatiotesti Testi, joka testaa useamman yksikön yhteistoimintaa Järjestelmätesti Testi, joka testaa koko järjestelmää kerralla Yleensä käyttöliittymätason testi Oikealla esitetään tyypillisimmät automatisoidut testityypit
TDD Test-driven Development Testiohjattu kehitys
Mikä TDD? Test-driven development (TDD) eli testiohjattu kehitys on ohjelmistokehitysmenetelmä, jossa kehittäjä kirjoittaa testin ennen varsinaisen toteutuskoodin kirjoittamista TDD:llä on kahdenlainen tarkoitus: Toimia matalan tason suunnittelun lähtökohtana Taata kattava testaus yksikkö- ja integraatiotestaustasolla Pääasiallisena korkeamman tason motivaationa siis laadun varmistaminen Kattavan testipatteriston avulla minimoidaan regressio ja täten muutosten tekeminen on helpompaa
TDD:n suhtautuminen perinteiseen kehitykseen Perinteinen ohjelmistokehityssykli Suunnittele Toteuta Testaa Testiohjattu ohjelmistokehityssykli Testaa Toteuta Suunnittele Test Code Refactor
Test Code Refactor Toteutus etenee lyhyissä sykleissä Syklin pituus muutamasta kymmenestä sekunnista viiteen minuuttiin Ensin kirjoitetaan testi, joka testaa yksinkertaista osuutta toteutettavasta toiminnasta Tätä testiä vasten kirjoitetaan haluttu toiminnallisuus Lopuksi refaktoroidaan sekä testiä, että sovelluskoodia mikäli sille on tarvetta Refaktoroi Toteuta Testi on TDD:ssä tapa määritellä tulevan ohjelmakoodin sisältö Testillä on siis dualistinen luonne sovelluskoodiin: se sekä määrittelee, että testaa Testaa
Refaktorointi Oleellinen osa TDD:tä on refaktorointi Refaktoroinnilla tarkoitetaan toimintaa, jolla muutetaan olemassaolevan sovelluskoodin sisäistä rakennetta muuttamatta kuitenkaan ulospäin näkyvää toiminnallisuutta public int calculatevalue(int start) { if (start < 0) { throw new InvalidParameterException(); else if (start == 0) { return 0; return (somevalue * myattributevalue) / start; public int calculateanothervalue(int start) { if (start < 0) { throw new InvalidParameterException(); else if (start == 0) { return 0; return (someanothervalue * myattributevalue) / start; Refaktorointi public int calculatevalue(int start) { if (checkstartvaluevalidity()) { return (somevalue * myattributevalue) / start; return 0; public int calculateanothervalue(int start) { if (checkstartvaluevalidity()) { return (someanothervalue * myattributevalue) / start; return 0; private boolean checkstartvaluevalidity(int value) { if (value < 0) { throw new InvalidParameterException(); else if (value == 0) { return false; return true;
Aieperustainen ohjelmointi Aieperustainen ohjelmointi (Programming by Intention) on oleellinen osa TDD:tä, vaikka ei suoraan liitykään mitenkään testaukseen Tarkoituksena on lähestyä ohjelmakoodin kehitystä black-box -ajattelulla Rajapintoja tehdessä ei mietitä toiminnallisuutta, vaan sitä miten kyseistä rajapintaa haluttaisiin käyttää Pyritään jakamaan ohjelmakoodi useisiin metodeihin/funktioihin, joiden nimet ovat mahdollisimman kuvaavia Jaottelua ei tehdä jälkikäteen, vaan ennen varsinaisen toteutuskoodin kirjoittamista Tarkoituksena on esittää ohjelmoijan aie tulevaisuuden toiminnallisuudsta
TDD:n historiaa Nykymuotoisen TDD:n alkujuuret löytyvät Extreme Programming -metodologian määritelmistä Ensimmäisen kerran esitetty erillään XP:stä Kent Beckin kirjassa Test-Driven Development by Example (Addison Wesley, 2003) TDD:n mukaista kehitystä on kuitenkin tehty jo paljon kauemmin Beck toi TDD:n uudestaan esille yhdistäessään sen osaksi XP:tä Samalla TDD sai tarkemman määrittelyn Nykyään TDD on saanut paljon huomiota myös XP:n harrastajien ulkopuolella
TDD:n monet kasvot TDD terminä on nykyisellään hyvin monikäsitteinen Aina kun puhutaan TDD:stä, täytyy myös tietää että mitä muotoa TDD:stä tarkoitetaan Roy Osherov esittää TDD:n esiintyvän neljässä eri muodossa: 1) Testiohjattu kehitys: Ajatus siitä, että kirjoitetaan testi ennen sovelluskoodia. Voidaan noudattaa olemassaolevaa arkkitehtuurisuunnitelmaa. 2) Testisuuntautunut kehitys: Testejä kirjoitetaan paljon, mutta ei välttämättä ennen sovelluskoodia. Arkkitehtuuri on yleensä selvillä ennen testin kirjoittamista. 3) Testiohjattu suunnittelu (alkuperäinen XP-tapa): Käytetään TDD:tä kokonaisvaltaisena suunnittelutyökaluna. Testit ohjaavat koko suunnitteluprosessia ja käytännössä sovellusarkkitehtuuri suunnitellaan lennossa testien ohjaamana. 4) Testiohjattu kehitys ja suunnittelu: Käytetään testit-ensin -periaatetta uuden ohjelmakoodin tuottamisen lähteenä ja samalla annetaan sen muuttaa olemassaolevaa arkkitehtuuria. Suuren linjan arkkitehtuuri on kuitenkin erikseen päätettynä paikallaan ja evolutionääriset muutokset suuntautuvat pienemmän skaalan asioihin.
TDD ja kritiikki TDD on saanut osakseen huomattavan paljon kritiikkiä Suurin osa tästä kritiikistä koskee juurikin alkuperäistä XP:n esittelemää muotoa TDD:stä Ehkä tunnetuin arvostelija on James Cope Coplien. Alkuperäinen XP:n määritelmä TDD:stä määrittelee termin emerging design, joka käytännössä tarkoittaa arkkitehtuurin kasvamista kehityksen myötä ilman etukäteissuunnittelua Tällaisella lähestymistavalla on lähinnä heikentävä vaikutus arkkitehtuuriin ja mm. VTT:llä ovat Abrahamsson ja Sinisalo tehneet tutkimusta aiheesta
Esimerkki: CurrencyConverter package fi.kilosoft.tdd; import java.math.bigdecimal; public class CurrencyConverter { public static void main (String[] args) { String amountstr = args[0]; String startingcurrency = args[1]; String targetcurrency = args[2]; CurrencyConverter converter = new CurrencyConverter(startingCurrency, targetcurrency); BigDecimal amount = converter.converttotargetcurrency(amountstr); System.out.println(amount + " " + converter.gettargettype()); private CurrencyType startingtype; private CurrencyType targettype; public CurrencyConverter(String startingcurrency, String targetcurrency) { startingtype = new CurrencyType(startingCurrency); targettype = new CurrencyType(targetCurrency); Toteutetaan CurrencyConverter -luokan käyttämä CurrencyType testiohjatusti public BigDecimal converttotargetcurrency(string amount) { BigDecimal startingamount = new BigDecimal(amount); return targettype.calculateamount(startingamount, startingtype); public CurrencyType gettargettype() { return targettype;
Esimerkki, jatkuu... @Test public void testcreatingeuro() { String eur = "EUR"; CurrencyType type = new CurrencyType(eur); assertequals(eur, type.gettypeasstring()); public CurrencyType(String type) { public String gettypeasstring() { return "EUR"; @Test public void testcreatingusdollar() { String eur = "USD"; CurrencyType type = new CurrencyType(eur); assertequals(eur, type.gettypeasstring()); private String type; public CurrencyType(String type) { this.type = type; public String gettypeasstring() { return type; private static ResourceBundle currencies; @BeforeClass public static void setupclass() { currencies = ResourceBundle.getBundle("currencies"); /** * http://en.wikipedia.org/wiki/iso_4217 */ @Test public void testvalidiso4217currenciesareaccepted() { Enumeration<String> keys = currencies.getkeys(); while (keys.hasmoreelements()) { new CurrencyType(keys.nextElement()); currencies.properties, sisältää validit valuuttatunnukset Vihreä palkki ei muutoksia toteutukseen luodaan uusi testi
Esimerkki jatkuu edelleen... @Test(expected = CurrencyConversionException.class) public void testinvalidcurrencystring() { new CurrencyType("foo"); public CurrencyType(String type) { if (type.equals("foo")) { throw new CurrencyConversionException(); @Test public void testinvalidcurrenciesthrowexception() { Enumeration<String> keys = ResourceBundle.getBundle("currencies").getKeys(); while (keys.hasmoreelements()) { String elem = keys.nextelement(); try { new CurrencyType(elem.concat("A")); fail("invalid currency type accepted"); catch (CurrencyConversionException cce) { /* all well, we got here */ try { new CurrencyType(elem.substring(1).concat("Ö")); fail("invalid currency type accepted"); catch (CurrencyConversionException cce) { /* all well, we got here */ private static final ResourceBundle currencies; Huono ratkaisu, miksi? Refaktoroidaan seuraavalla kalvolla paremmaksi static { currencies = ResourceBundle.getBundle("currencies"); public CurrencyType(String type) { if (!currencies.containskey(type)) { throw new CurrencyConversionException(); this.type = type;
Esimerkki: refaktorointia Final pois ja setter staattisen rakentajan tilalle private static ResourceBundle currencies = null; public static void setcurrencies(resourcebundle currencies) { CurrencyType.currencies = currencies; public CurrencyType(String type) { if (currencies == null) { currencies = ResourceBundle.getBundle("currencies"); if (!currencies.containskey(type.touppercase())) { throw new CurrencyConversionException(); this.type = type; NullPointerExceptionin välttämiseksi alustetaan currencies jos setteriä ei ole kutsuttu ennen olion luontia Muutos mahdollistaa joustavamman testauksen, sillä nyt CurrencyType ei ole kiinteästi riippuvainen currencies.properties -tiedoston sisällöstä voidaan simuloida helpommin niin virhetilanteita kuin oikeaa toiminnallisuuttakin
...ja esimerkin loppu @Test public void testeurotoeuroconversion() { CurrencyType start = new CurrencyType("EUR"); CurrencyType target = new CurrencyType("EUR"); BigDecimal value = target.calculateamount(new BigDecimal("100"), start); assertequals(new BigDecimal("100"), value); value = target.calculateamount(new BigDecimal("10"), start); assertequals(new BigDecimal("10"), value); public BigDecimal calculateamount(bigdecimal startingamount, CurrencyType startingtype) { if (startingtype.gettypeasstring().equals(this.gettypeasstring())) { return startingamount; return new BigDecimal("100"); @Test public void testeurotousdconversion() { CurrencyType start = new CurrencyType("EUR"); CurrencyType target = new CurrencyType("USD"); BigDecimal usdamount = new BigDecimal("100"); BigDecimal expected = usdamount.multiply(new BigDecimal(currencies.getObject("USD").toString())); BigDecimal value = target.calculateamount(usdamount, start); assertequals(expected, value); Duplikoi sovelluslogiikkaa testeihin, hyvä refaktorointikohde! Ja niin poispäin...
TDD ja CI ne yhteen sopii Jatkuva integraatio (Continuous Integration, CI) on TDD:n tehokkaalle hyödyntämiselle lähes pakollinen CI on hyödyllinen vasta jos on testejä ajettavaksi ja TDD on hyödyllinen vain jos kirjoitettuja testejä ajetaan Luonnollinen yhdistelmä Käytännössä jossain vaiheessa täysien testisettien ajaminen jatkuvasti osana TDD-sykliä muuttuu mahdottomaksi Suoritusaika kasvaa liian pitkäksi Järjestelmä/hyväksymistestivaiheen testejä ei välttämättä edes haluta tai voida ajaa kehityskoneella
ATDD Acceptance Test-driven Development Hyväksymistestivetoinen kehitys
Perinteiset määrittelyt eivät toimi Tiukat vesiputousmallin mukaiset etukäteismäärittelyt eivät ikinä kuvaa täysin sitä, mitä oikeasti halutaan Ideoita tulee matkan varrella lisää niin kehitystiimin kuin asiakkaankin suunnalta Kaikkea ei vain osata ottaa huomioon Ristiriitaisuuksia määrittelyn eri osien kohdalla on lähes aina Eri ihmiset tulkitsevat saman asian eri tavalla Ketterät menetelmät yrittävät vastata tähän ja onnistuvat osittain
Mihin agile ei sitten vastaa? Ketterät menetelmät tuovat määrittelyyn iteratiivisuuden TDD tuo iteratiivisuuden varsinaiseen kehitysprosessiin! Ketterät menetelmät eivät tuo yksikäsitteisiä määritelmiä Päinvastoin, kun määritellään vähemmän asioita kerralla joudutaan myöhemmin muuttamaan asioita Pääsääntöisesti tämä on ihan OK ja hyväksyttävää: sovelluksen laatu paranee kun hyväksytään muutoksien mahdollisuus Suureksi ongelmaksi jää kuitenkin inhimilliset tulkintaerot Tämän ongelman ratkaisemiseksi on yritetty vuosien varrella suurinpiirtein kaikkea: tiukat taulukkomuotoiset käyttötapaukset, käyttötarinat jne jne Ketterät menetelmät (varsinkin Scrum) painottavat valmiuden määritelmää antamatta kuitenkaan mitään eväitä sen määrittelemiseksi!
Vaatimukset ja testit kohtaavat Vaatimus Hyväksymistesti Toteutus Palaute Ohjataan toteutusprosessia joukolla automatisoituja ja suoritettavia hyväksymistestejä
Hyväksymistestit määrittelynä Hyväksymistestivetoinen kehitys (ATDD) on keino tehdä sovellukselle määrittely, jota vasten sovelluksen toiminnallisuus voidaan automaattisesti todeta Tulkintaeroja ei käytännössä voi tulla Perusideana on tehdä automaattisesti suoritettava testi ennen toiminnallisuuden toteuttamisen aloittamista Toiminnallisuus tehdään hyväksymistestiä vasten Kun testi menee läpi toiminnallisuus on tehty Hyväksymistestit tekee asiakas Hetkonen? Miten ei-tekninen ihminen voi tehdä teknisiä automaattisesti suoritettavia testejä?
Asiakas osana hyväksymistestausta On oleellista, että hyväksymistestien pääpihvi on nimenomaan asiakkaan tekemää Asiakas itse (yleensä) tietää parhaiten mitä haluaa Käytännössä lopullista suoritettavaa testiä ei kuitenkaan asiakas voi tehdä Työ tehdään tiiviissä yhteistyössä toimittajan määrittelijän kanssa, aivan kuten ennenkin! Asiakas voi kuitenkin tehdä perinteistä taulukkomuotoista määrittelyä vastaavan ohjeistuksen, jonka tietojen perusteella automaattinen testi voidaan suorittaa Tämän asiakas voi naputella vaikkapa tutulla ja turvallisella Wordillä tai vastaavalla työkalulla
ATDD:n prosessi Määrittelytyöryhmä luo sekä vaatimukset, että suoritettavat hyväksymistestit lyhyiden käyttötarinoiden kautta (User Stories) Mukana liiketoimintaympäristöstä, sekä teknisistä asioista ymmärtäviä henkilöitä Prosessi on jatkuva ja tapahtuu läpi projektin Suoritettavat testit määrittelevät Scrumin Product Backlogin Oleellisena erona perinteiseen hyväksymistestaukseen on asiakkaan suora osallistuminen testien tekemiseen Määrittelytyöryhmä Projektipäällikkö Asiakas Pääsuunnittelija Testausvastaava Määrittelevät Hyväksyy Toteuttaa Vaatimukset Suoritettavat testit Perusteella
ATDD:n työkalut Jotta ATDD:tä voisi käyttää tehokkaasti on sitä varten käytettävä siihen sopivia työkaluja Erilaisiin sovellusympäristöihin on olemassa omia spesifejä työkalujaan Fit, SLIM, Robot Framework... Suurimmalle osalle työkaluista yhteistä on se, että testien syötemateriaali kuvataan taulukoina Helppo lukea Helppo tulkita testikoodissa
Esimerkki (Fit) fi.kilosoft.acceptance.examplefixture change 100 from USD to EUR result should be 71.97 change 50 from SEK to EUR result should be 5.37 public boolean changefromtoresultshouldbe(int amount, String fromtype, String totype, BigDecimal shouldbe) { CurrencyConverter converter new CurrencyConverter(fromType, totype); return shouldbe.equals(converter.converttotargetcurrency(amount)); Työkalut tulkitsevat testisivujen taulukoiden sisällön Kaikki muu sisältö on vapaamuotoista Esimerkki vain yksi tapa käyttää Fit-frameworkia
Miten perustella tiimille? ATDD tuo näennäistä lisätaakkaa tiimille Todellisuudessa työmäärä pienenee koko projektin aikana Ei enää arpomista sen suhteen, että mitä tietyt lausemuodot määrittelyssä oikeasti tarkoittavat Ei enää miettimistä, että tulikohan nyt varmasti tehtyä kaikki vaadittu Kun testi menee läpi, niin vaatimuksen ominaisuudet on tehty Scrum: Definition of Done Ei enää kädenvääntöä asiakkaan kanssa, että mikä on määriteltyä toiminnallisuutta ja mikä on muutospyyntö Yhdessä ketterien menetelmien kanssa todella vahva työkalu!
Miten perustella asiakkaalle? Yhdistettynä jatkuvaan integraatioon on asiakkaalla mahdollisuus nähdä koska tahansa projektin todellinen tila Testit ovat asiakkaan itsensä hyväksymiä Testit eivät valehtele Lisää luottamusta projektin etenemiseen Väärinymmärryksien mahdollisuus pienenee koska määrittelyssä on yksi vaihe lisää, jolla varmistetaan että vaatimus on ymmärretty oikein: suoritettavan hyväksymistestin kirjoittaminen Todennäköisempää saada mitä haluaa
Ongelmat Asiakkaan opettaminen testilähtöiseen lähestymiseen voi olla työn ja tuskan takana Käytännössä asiakkaalla on pakko olla edes hitusen teknistä ymmärrystä Valitettavan usein ATDD:tä ei voida käyttää täysipainoisesti koska asiakas ei siihen suostu Tällöin määrittelyprosessi menee asiakasrajapinnassa kuten ennenkin ja määrittely muunnetaan suoritettaviksi hyväksymistesteiksi Tällöin asiakkaan varmistus testin oikeellisuudesta jää pois Eroavaisuudet perinteiseen hyväksymistestaukseen enää hyvin pienet Riippuen sovellusalustasta voi automatisoitujen järjestelmätason testien kirjoittaminen olla hyvin työlästä Esim. sulautetut järjestelmät
Luettavaa Test-Driven Development by Example, Kent Beck (Addison Wesley, 2003) Test Driven, Lasse Koskela (Manning, 2007) Bridging the Communication Gap, Gojko Adzic (Neuri Limited, 2009) Ja tietysti Google :)
Kysymyksiä, kommentteja, muita murheenaiheita?
Kiitos mielenkiinnostanne! Niklas Collin Software Architect Kilosoft Oy +358 40 058 2757 niklas.collin@kilosoft.fi