Introduksjon til TDD i et .NET/C#-perspektiv. Inneholder historie, forklarer hvorfor TDD ble innført og hvilke fordeler testdrevet utvikling fører med seg, beskriver FIRST-prinsippene, red-green-refactor og Arrange, Act, Assert, mocking og anbefalinger for videre lesning. Beskriver nUnit, moq og AutoFixture, som Creuna har standardisert seg på.

1. Test Driven Development
@Joachim_L

2. 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.

3. 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.

4. 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.

5. 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?

6. Hvordan?
Skriv tester for kode du skulle ønske du
hadde
TCYWYH – The Code You Wish You Had

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

8. 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

9. Hvordan?
Testene skrives i henhold til FIRST-prinsippene:
• Fast
• Independent
• Repeatable
• Self-checking
• Timely

10. Hvordan?
Testene skrives i henhold til FIRST-prinsippene:
• Fast
• Independent
• Repeatable
• Self-checking
• Timely

11. 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.

12. Hvordan?
• Fast
• Independent
• Repeatable
• Self-checking
• Timely

13. 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.

14. Hvordan?
• Fast
• Independent
• Repeatable
• Self-checking
• Timely

15. Repeatable
Testene må gi samme resultat uavhengig av hvor
mange ganger de kjøres.
• Igjen ved bruk av f.eks SetUp-attributter i nUnit for å gjenskape opprinnelig
state.
• Unngå avhengigheter til eksterne systemer.

16. Hvordan?
• Fast
• Independent
• Repeatable
• Self-checking
• Timely

17. Self-checking
Testene må automatisk vite om de er passert og
godkjent.
• Ingen manuelle rutiner/operasjoner (ingen output må verifiseres manuelt
eller observasjoner av annen art må gjøres).

18. Hvordan?
• Fast
• Independent
• Repeatable
• Self-checking
• Timely

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

20. 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()

21. 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.

22. Hvordan?
• Arrange
• Act
• Assert

23. Arrange
• Om nødvendig:
• Sørg for at systemet er i samsvar med forutsetninger.
• Lag inputparametre
• Sett opp mocking

24. Hvordan?
• Arrange
• Act
• Assert

25. Act
• Gjør metodekallet som sørger for at koden som skal testes blir kjørt.
• Ta vare på eventuell returverdi.

26. Hvordan?
• Arrange
• Act
• Assert

27. Assert
• Verifiser at koden har gjort dene ene tingen som testen forventer.
• Returnert riktig verdi
• Kastet forventet Exception

28. Hvordan?
• Testpyramiden beskriver forholdet mellom antall tester av forskjellige
typer.
Enhetstester
GUI-
tester
Integrasjons-, komponent-
og/eller akseptansetester
Manuell testing

29. 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.

30. 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.

31. Verktøy - Mocking
• Bruk mocks (liksomobjekter) for å jukse til avhengigheter man ikke
har kontroll på.
• Webservicer
• Databaser
• Web APIer
• Moq

32. 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.

33. 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.

34. Videre lesning
• Test Driven Development: By Example, Kent Beck

35. Videre lesning
• Test Driven Development: By Example, Kent Beck
• Growing Object-Oriented Software, Guided by Tests [Paperback]

36. Videre lesning
• Test Driven Development: By Example, Kent Beck
• Growing Object-Oriented Software, Guided by Tests [Paperback]
• Professional Test Driven Development with C#

37. Eksempler
• Enhetstester
• Integrasjonstest
• GUI-tester

38. Eksempler
• Enhetstester
• Integrasjonstest
• GUI-tester

39. Eksempler
• Enhetstest
• Integrasjonstest
• GUI-tester

40. Eksempler
• Enhetstest
• Integrasjonstest
• GUI-tester

41. Eksempler
• Enhetstest
• Integrasjonstest
• GUI-tester

42. Takk!