TDD

Testbar arkitektur og design (se også  wikipedia) går ut på å sørge for at man designer for at system og komponenter er:

  • Kontrollerbar: Det bør være mulig å kontrollere status før og etter kjøring av test slik at det er mulig å repetere tester.
  • Observerbar: Grad av mulighet til å kontrollere status under testing.
  • Mulig å automatisere: Tester bør kunne automatiseres.
  • Isolering: Muligheten for å teste komponenter isolert.

 

Test dreven utvikling (TDD) går i korthet ut på å skrive enhets tester før man implementerer ny funksjonalitet. Dette gjøres gjerne i små steg:

  1. Skriv en test for å dekke funksjonaliteten.
  2. Kjør testene og se at testen feiler.
  3. Implementer funksjonaliteten.
  4. Kjør testene og se at testen ikke feiler (evt. gå tilbake til 3 og fiks).

Noen av fordelene med test dreven utvikling er:

  • Automatiserte tester reduserer generel risiko for feil, og ikke minst for å repetere feil.
  • Med gode automatiserte tester er det lettere å gjøre strukturelle kode-endringer (refactoring) for å bekjempe entropi og forhindre big ball of mud arkitektur).
  • Ofte vil test dreven utvikling hjelpe til å sikre renere design og bedre kode. Dette igjen fører til økt produktivitet på tross for ekstra tid brukt på å skrive tester.