tdd ja atdd - tunitie21201/s2010/luennot/collin.pdf · 2010. 11. 15. · tdd ja ci ne yhteen sopii...

TDD ja ATDD

Niklas Collin

Naulakatu 3, 33100 Tamperewww.kilosoft.fi

Kilosoft Oy | Naulakatu 3 | 33100 Tampere | Finland | www.kilosoft.fi | www.titannms.com

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ä sanastoa2) 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

● 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ä

● Oikealla esitetään tyypillisimmät automatisoidut testityypit

● Yksikkötesti● 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


TDDTest-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

Testiohjattu ohjelmistokehityssykli

Suunnittele Toteuta Testaa

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

Testaa

Toteuta

Refaktoroi

● Testi on TDD:ssä tapa määritellä tulevan ohjelmakoodin sisältö

● Testillä on siis dualistinen luonne sovelluskoodiin: se sekä määrittelee, että 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;}

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;

}

Refaktorointi


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





● Samalla TDD sai tarkemman määrittelyn





● Samalla TDD sai tarkemman määrittelyn


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äärisetmuutokset 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); } public BigDecimal convertToTargetCurrency(String amount) { BigDecimal startingAmount = new BigDecimal(amount); return targetType.calculateAmount(startingAmount, startingType); } public CurrencyType getTargetType() { return targetType; }}

Toteutetaan CurrencyConverter -luokan

käyttämä CurrencyType testiohjatusti


Esimerkki, jatkuu...

@Testpublic void testCreatingEuro() {

String eur = "EUR";CurrencyType type = new CurrencyType(eur);assertEquals(eur, type.getTypeAsString());

}

public CurrencyType(String type) {}

public String getTypeAsString() {return "EUR";

}

@Testpublic 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;@BeforeClasspublic static void setupClass() {

currencies = ResourceBundle.getBundle("currencies");}/** * http://en.wikipedia.org/wiki/ISO_4217 */@Testpublic void testValidISO4217CurrenciesAreAccepted() {

Enumeration<String> keys = currencies.getKeys();while (keys.hasMoreElements()) {

new CurrencyType(keys.nextElement());}

}

Vihreä palkki → ei muutoksia toteutukseen → luodaan uusi testi

currencies.properties, sisältää validitvaluuttatunnukset


Esimerkki jatkuu edelleen...

@Test(expected = CurrencyConversionException.class)public void testInvalidCurrencyString() {

new CurrencyType("foo");}

public CurrencyType(String type) {if (type.equals("foo")) {

throw new CurrencyConversionException();}

}

@Testpublic 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;static {

currencies = ResourceBundle.getBundle("currencies");}

public CurrencyType(String type) {if (!currencies.containsKey(type)) {

throw new CurrencyConversionException();}this.type = type;

}

Huono ratkaisu, miksi?Refaktoroidaan seuraavallakalvolla paremmaksi


Esimerkki: refaktorointia

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;

}

Final pois ja setter staattisenrakentajan tilalle

NullPointerExceptionin välttämiseksialustetaan currencies jos setteriä eiole kutsuttu ennen olion luontia

Muutos mahdollistaa jous-tavamman testauksen,sillä nyt CurrencyType eiole kiinteästi riippuvainencurrencies.properties-tiedoston sisällöstä →voidaan simuloida helpomminniin virhetilanteita kuin oikeaatoiminnallisuuttakin


...ja esimerkin loppu

@Testpublic 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");

}

@Testpublic 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);

}

Ja niin poispäin...

Duplikoi sovelluslogiikkaa testeihin, hyvä refaktorointikohde!


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


ATDDAcceptance 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 ToteutusPalaute

● 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


● 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

ATDD:n prosessi

Määrittelytyöryhmä

Projektipäällikkö

Asiakas

Pääsuunnittelija

Testausvastaava

VaatimuksetMäärittelevät

Suoritettavattestit

Toteuttaa

Perusteella

Hyväksyy


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.ExampleFixturechange 100 from USD to EUR result should be 71.97

change 50 from SEK to EUR result should be 5.37

● Työkalut tulkitsevat testisivujen taulukoiden sisällön● Kaikki muu sisältö on vapaamuotoista● Esimerkki vain yksi tapa käyttää Fit-frameworkia

public boolean changeFromToResultShouldBe(int amount, String fromType, String toType, BigDecimal shouldBe) { CurrencyConverter converter new CurrencyConverter(fromType, toType); return shouldBe.equals(converter.convertToTargetCurrency(amount));}


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, muitamurheenaiheita?


Niklas CollinSoftware ArchitectKilosoft Oy+358 40 058 [email protected]

Kiitos mielenkiinnostanne!

tdd ja atdd - tunitie21201/s2010/luennot/collin.pdf · 2010. 11. 15. · tdd ja ci ne yhteen sopii...

Documents