Testdrivet arbete - en förutsättning för Continuous Delivery

En av de tekniker som jag anser vara absolut nödvändig att behärska för att lyckas med Continuous Delivery är att arbeta testdrivet. Beroende på vilken nivå testerna skrivs så bidrar de på olika sätt. De nivåer som man brukar tala om är enhetstestnivå, komponenttestnivå och acceptanstestnivå. I den här artikeln kommer jag främst att inrikta mig på accpetanstestnivån, även om delar av argumenten kan appliceras på de andra nivåerna.

Continuous Delivery

Continuous Delivery är något som konstant ökat i popularitet de senaste åren och har blivit ett etablerat begrepp när Jez Humble och David Farley publicerade boken Continuous Delivery. I takt med att fördelarna blir kända ökar även nyfikenheten att som organisation själv implementera Continuous Delivery. Det är förståeligt då Continuous Delivery,  om införandet är utfört på ett bra sätt, kan öka produktiviteten markant, samtidigt som ledtiden att få ut ny funktionalitet minskar och kvaliteten på det arbete som produceras hålls på en hög nivå. Självklart att Continuous Delivery blir intressant när det erbjuder sådana fördelar!

Acceptanstestdrivet arbete

Specification by Example, Behaviour Driven Development (BDD) och Acceptance Test Driven Development (ATDD), försöker alla beskriva ett arbetssätt där ett systems beteende specificeras på ett visst format i syfte att kunna användas som både dokumentation och exekverbara test. Det är viktigt att lejonparten av specifikationerna skrivs innan den nya funktionaliteten börjar utvecklas då det bidrar till att lyckas med Continuous Delivery

Det ovärdeliga bidraget som testdrivet arbete ger till Continuous Delivery  har flera fördeler.

  • Den samlade massan av exekverbara specifikationer fungerar som en regressionstestsvit vilket gör att vi utan nervositet kan produktionssätta nya funktioner snabbare.
  • För att kunna använda specifikationen som automatiskt test måste den vara tydlig vilket gör att vi lättare vet när vi är klara.
  • Eftersom de exekverbara specifikationerna skrivs innan funktionaliteten utvecklas är risken minimal att otestad kod existerar under någon längre tid.
  • De exekverbara specifikationerna dokumenterar systemets beteende och gör att vi lätt kan kommunicera hur systemet fungerar.

Fördelarna som finns att hämta från acceptanstestdrivet arbete är också förutsättningar för att lyckas med Continuous Delivery. För att fördelarna av acceptanstestdrivet arbete ska bli framträdande krävs diciplinerat arbete. Den samling tekniker och arbetssätt som ryms inom Continuous Delivery är just bara tekniker och arbetssätt.  För att lyckas med ett införande krävs det förutom de tekniska aspekten en stark kultur, processer som stödjer arbetet och kompetens.

Sammanfattning

När en organisation valt att börja arbete enligt Continuous Delivery är det viktigt att man arbetar testdrivet med automatiska acceptanstester. Om de automatiska acceptanstesterna inte är på plats innan ny funktionalitet utvecklas riskerar man att den är otestad under en tid. Uppenbara risker med detta är bland annat att felaktig funktionalitet hamnar i produktion, och att framtida förändringar tar sönder den otestade funktionaliteten. Samtidigt försvinner spårbarheten och pålitligheten som gör det möjligt att få de riktigt stora fördelarna med Continuous Delivery.  Risken är då stor att missa det stora målet med Continuous Delivery - alltså att leverera högkvalitativ mjukvara på ett reproducerbart sätt över tid.

Det är inte alltid enkelt - som tur är finns det mönster att använda som ökar chansen att lyckas. Mer om det i en framtida artikel.

Martin Johansson
martin.johansson@metrical.se