Test Driven Development@Joachim_L

Hva?

• «Gjenoppdaget» av Kent Beck tidlig på 2000-tallet.• Ga ut boka «Test Driven Development: By Example» i 2002

• Har sitt utspring i Extreme Programming-bevegelsens test first-filosofi• Kent Beck bidro til å utforme «The Agile Manifesto» i 1999.

• Beskriver en utviklingsmetodikk med en svært kort syklus («red-green-refactor») .

• Oppfordrer til enkelt design og øker tilliten til koden.

Hva?

• Handler først og fremst om design, ikke testing.

• Forskjellige typer• Unit tests (enhetstester)

• Integrations tests (integrasjonstester)

• End-to-end tests (systemtester)

• Outside-in eller inside-out.

Hvorfor?

• Utviklere gjør feil.“58% of software bugs result from test infrastructure and process, not design defects” (Electric Cloud, 2. juni 2010)

• Jo tidligere man finner en feil, jo billigere er den å fikse.• I TDD skrives testene før systemkoden – altså så tidlig som mulig.

• Testene sikrer at systemet implementerer designet.

• Testene er APIets første brukere.

Hvorfor?

• Mindre tid i debuggeren

• Eksisterende tester sikrer at ny kode ikke ødelegger eksisterende funksjonalitet (regresjon)

• Gjør det lettere å skrive CLEAN-kode.• Red-green-refactor sikrer at refactoring-prosessen kun endrer

implementasjon, ikke funksjonalitet.

• Kontinuerlig mestringsfølelse• Alle liker vel grønne lys?

Hvordan?

Skriv tester for kode du skulle ønske du hadde

TCYWYH – The Code You Wish You Had

Test First Development

1. Identifiser én ting koden skal gjøre.

2. Skriv en test som verifiserer at koden gjør den éne tingen.

3. Kjør testen (manuelt eller automatisk)

4. Skriv kode som gjør at systemet består testen.• I denne fasen fokuserer man på at koden gjør det den skal, ikke at den er pen.

5. Refactor. (Gjør koden pen.)

6. Gå til pkt. 1

Test First Development

1. Identifiser én ting koden skal gjøre.

2. Skriv en test som verifiserer at koden gjør den éne tingen.

3. Kjør testen (manuelt eller automatisk)

4. Skriv kode som gjør at systemet består testen.• I denne fasen fokuserer man på at koden gjør det den skal, ikke at den er pen.

5. Refactor. (Gjør koden pen.)

6. Gå til pkt. 1

Red

Test First Development

1. Identifiser én ting koden skal gjøre.

2. Skriv en test som verifiserer at koden gjør den éne tingen.

3. Kjør testen (manuelt eller automatisk)

4. Skriv kode som gjør at systemet består testen.• I denne fasen fokuserer man på at koden gjør det den skal, ikke at den er pen.

5. Refactor. (Gjør koden pen.)

6. Gå til pkt. 1

Red

Green

Test First Development

1. Identifiser én ting koden skal gjøre.

2. Skriv en test som verifiserer at koden gjør den éne tingen.

3. Kjør testen (manuelt eller automatisk)

4. Skriv kode som gjør at systemet består testen.• I denne fasen fokuserer man på at koden gjør det den skal, ikke at den er pen.

5. Refactor. (Gjør koden pen.)

6. Gå til pkt. 1

Red

GreenRefactor

Test First Development

1. Identifiser én ting koden skal gjøre.

2. Skriv en test som verifiserer at koden gjør den éne tingen.

3. Kjør testen (manuelt eller automatisk)

4. Skriv kode som gjør at systemet består testen.• I denne fasen fokuserer man på at koden gjør det den skal, ikke at den er pen.

5. Refactor. (Gjør koden pen.)

6. Gå til pkt. 1

Red

GreenRefactor

Test First Development

1. Identifiser én ting koden skal gjøre.

2. Skriv en test som verifiserer at koden gjør den éne tingen.

3. Kjør testen (manuelt eller automatisk)

4. Skriv kode som gjør at systemet består testen.• I denne fasen fokuserer man på at koden gjør det den skal, ikke at den er pen.

5. Refactor. (Gjør koden pen.)

6. Gå til pkt. 1

Red

GreenRefactor

Hvordan?

Testene skrives i henhold til FIRST-prinsippene:

• Fast

• Independent

• Repeatable

• Self-checking

• Timely

Hvordan?

Testene skrives i henhold til FIRST-prinsippene:

• Fast

• Independent

• Repeatable

• Self-checking

• Timely

Fast

Testene må være raske, ettersom de kjører kontinuerlig.• Enhetstester må være raskere enn integrasjonstester som må være raskere

enn systemtester.

• Avhengigheter til andre systemer og moduler unngås, typisk med mocks og stubs.

• Et verktøy som nCrunch kan automatisk kjøre tester som berøres når kode endres.

Hvordan?

• Fast

• Independent

• Repeatable

• Self-checking

• Timely

Independent

Testene må være uavhengige av hverandre• Tester må gi samme resultat uavhengig av rekkefølgen de blir kjørt i.

• En test kan ikke være avhengig av en annen tests resultat (eller klar over dens eksistens).

• Bruk av f.eks SetUp-attributter i nUnit for å gjenskape opprinnelig state.

Hvordan?

• Fast

• Independent

• Repeatable

• Self-checking

• Timely

Repeatable

Testene må gi samme resultat uavhengig av hvormange ganger de kjøres.

• Igjen ved bruk av f.eks SetUp-attributter i nUnit for å gjenskape opprinnelig state.

• Unngå avhengigheter til eksterne systemer.

Hvordan?

• Fast

• Independent

• Repeatable

• Self-checking

• Timely

Self-checking

Testene må automatisk vite om de er passert oggodkjent.

• Ingen manuelle rutiner/operasjoner (ingen output må verifiseres manuelt eller observasjoner av annen art må gjøres).

Hvordan?

• Fast

• Independent

• Repeatable

• Self-checking

• Timely

Timely

Testene skal skrives til rett tid og alltid før systemkoden.• Enhetstester skal skrives umiddelbart før koden den dekker.

Hvordan?

Om en test feiler skal det ikke være noen tvil om hva som har gått galt.

• Hver enkelt test bør teste så lite som mulig. (Én assert per test.)

• Testens (testmetodens) navn bør ikke etterlate noen tvil om hva den tester.• Særs ille: private void private void TestPostMethod();

• Ikke bra: private void DoublePost() ;

• Bedre: private void DoublePostOnBlogFails();

• Best: private void Double_post_on_article_throws_DuplicatePostException()

Hvordan?

Bytt ut kall til eksterne avhengigheter med mocks og stubs.

• Fordrer at man har kode skrevet etter Inversion of Control-prinsippet.

• Bruk et mocking-rammeverk om en stub ikke holder.

Hvordan?

• Arrange

• Act

• Assert

Arrange

• Om nødvendig:• Sørg for at systemet er i samsvar med forutsetninger.

• Lag inputparametre

• Sett opp mocking

Hvordan?

• Arrange

• Act

• Assert

Act

• Gjør metodekallet som sørger for at koden som skal testes blir kjørt.

• Ta vare på eventuell returverdi.

Hvordan?

• Arrange

• Act

• Assert

Assert

• Verifiser at koden har gjort dene ene tingen som testen forventer.• Returnert riktig verdi

• Kastet forventet Exception

Hvordan?

• Testpyramiden beskriver forholdet mellom antall tester av forskjellige typer.

Enhetstester

GUI-tester

Integrasjons-, komponent-og/eller akseptansetester

Manuell testing

Verktøy - Testrammeverk

• Tester kan skrives uten et rammeverk, men…

• …et testrammeverk tilbyr• klasser, attributter og interfacer som forenkler oppsett og utforming av

testene

• En «runner» som kjører testene

• Faktiske grønne og røde (og av og til gule) indikatorer.

Verktøy - Testrammeverk

• nUnit• .net-port av javas jUnit.

• Stabil.

• Statisk

• Stagnert?

• Alternativer:• MSTest (Microsofts egen, som følger med Visual Studio).

• xUnit• Alt som er en [Fact] kjøres, i motsetning til nUnit, som krever [TestFixture] og [Test].

• Baserer seg på interfacer, ikke arv.

Verktøy - Mocking

• Bruk mocks (liksomobjekter) for å jukse til avhengigheter man ikke har kontroll på.• Webservicer

• Databaser

• Web APIer

• Moq

Verktøy - AutoFixture

• Kraftig verktøy for generering av data.

• Utviklere kan fokusere på funksjonaliteten som testes, ikke dataene som brukes.

• Kan utvides til å generere hele objektstrukturer med avansert logikk.

Verktøy - AutoFixture

• Kraftig verktøy for generering av data.

• Utviklere kan fokusere på funksjonaliteten som testes, ikke dataene som brukes.

• Kan utvides til å generere hele objektstrukturer med avansert logikk.

Videre lesning

• Test Driven Development: By Example, Kent Beck

Videre lesning

• Test Driven Development: By Example, Kent Beck

• Growing Object-Oriented Software, Guided by Tests [Paperback]

Videre lesning

• Test Driven Development: By Example, Kent Beck

• Growing Object-Oriented Software, Guided by Tests [Paperback]

• Professional Test Driven Development with C#

Takk!