Hvorfor bruge TDD (Test Driven Development) som udviklingsmetode.

Jeg har forsøgt, at bruge TDD som udviklingsmetode i et stykke tid. Det er bestemt ikke, altid jeg lever op til de 3 love for TDD, men jeg forsøger at følge dem mest muligt. I mit forsøg på, at udbrede denne metode til resten af mit team, har jeg i dag lavet et oplæg for teamet omkring TDD.

 

I denne blog har jeg taget hovedpunkterne fra min præsentation, og beskrevet hvorfor jeg er så begejstret for TDD.

The magic button

Forestil dig at din chef en tilfældig dag kommer ind til dig, og spørger om Jeres produkt er klar til at blive shipped om en time. Kunne det ikke være dejligt at have en magisk knap, du kunne trykke på, og så kan der et svar op om Jeres kode på nuværende tidspunkt have nogle kendte bugs. Dette kan opnås med TDD.

For mig er den magiske knap utrolig vigtig, og kan bruge til mange ting.

Robert C. Martin (Uncle Bob) Er rigtigt god til at fortælle om “den magiske knap”. Det gør han rigtigt godt ca. 35 min. inde i denne præsentation. Jeg kan klar anbefale, at se hele presentationen selvom den ikke kun omhandler TDD.

 https://www.youtube.com/watch?v=BSaAMQVq01E&list=PLGdSE37DDbcxT1lFuIMoHI28HxiS9uHuN

The 3 laws of TDD

  1. You can’t write any production code until you have first written a failing unit test.
  2. You can’t write more of a unit test than is sufficient to fail, and not compiling is failing.
  3. You can’t write more production code than is sufficient to pass the currently failing unit test.

 

Formålet med de 3 love er, at sikre at al kode er testet, når man er færdig med at udvikle en feature. Samtidig giver det en god følelse af fremskridt og kontorl, når man sidder og hopper frem og tilbage mellem test og design.

Som sagt overholder jeg ikke altid de 3 love, men prøver så vidt muligt at overholde dem.

Mine 3 største grunde til at bruge TDD

  1. Refactoring

Der er ingen der kan skrive perfekt kode i første forsøg. Jævnfør min erfaring er det altid en interaktiv process, at frembringe brugbart kode. Det betyder at man er nødt til at refactorere sin kode når man har fået koden til at virke. Her kommer TDD til sin fulde ret. Når man har den magiske knap er man ikke bange for at ændre koden. Man kan jo på få sekunder/minutter får, at vide om man har ødelagt noget.

2. Du er tvunget til at tænke test ind i sit design

Hvis man ikke følger TDD’s 3 love kommer man hurtigt til, at glemme at koden skal kunne testet. Og hvis koden er svær at teste, får man ikke testet den. Ved at følge de 3 TDD love husker man konstant på at koden skal testes, og man får lavet testede med det samme.

3. Du få besked inden for kort efter du har commited noget dårlig kode

Alle kommer til at checke dårlig kode ind. Det vigtigste er at man hurtigt får luget dårlig kode ud. Når man har et test system, der automatisk kører alle tests når ny kode bliver committed, har man ikke dårlig kode ret længde.

 

Karakteristisk ved en godt testcase

En god testcase er i TDD literaturen ti beskrevet med følgende karakteristika:

Is very limited in scope En testcase skal helst kun teste en ting. Det gør det meget nemmere, at debugge testcase’en. Jeg har tidligere haft lave nogle testcases der var meget store. Problemet med store testcases er, at det er bliver svære, at pinpointe hvilket område der fejler, og det tager forhåndvis lang tid, at køre testen. Når man debugger kan man hurtigt havde brugt for at køre testcase’en mange gange, og så er det vigtigt at den kan eksekveres hurtigt.
Clearly reveals its intention. Det er vigtigt, at man hurtigt kan forstå hvad en test skal teste. Derfor har jeg lagt ind i vores test framework, at man skal lave en beskrivelse af testen. Hvis man ikke gør det, vil testen blive market som fejlende.
Runs fast. Thjaa, mange siger at en testcase skal kunne køres på 100 ms. Det er nemt, at sige hvis man arbejder på en PC og ens program og kører på samme PC. Jeg arbejder med embedded systemer og crosscompilere.

Jeg vil helst kunne køre mit testsystem på en PC, og er nødt til at kommunikere med mit embedded system over en UART. Det betyder, at mine testcases normal tager 4-5 sec, hvilket er lang tid, hvis man har mange testcases, men det lever jeg med.

Does not depend on other units Der er mange der sværger til, at alle tests skal være unit tests, og kunne stå alene. Jeg er ikke enig. Jeg mener, at integration test (test der tester og tester interfaces mellem units) er meget vigtigere.

Det betyder, at jeg gerne tester en ny unit ved, at bruge en tidligere unit.

 

Leave a Reply

Your email address will not be published. Required fields are marked *