Specification by Example/BDD

---

Du har bestämt att Specification by Example (även kallat BDD) är något som är värt att pröva (kanske därför att du vill öka kravförståelsen och höja kodkvaliteten – och du kanske har ett existerande system som du vill börja använda det på.

Hur gör du då för att komma du igång?

Hur börjar man?

Den stora nyttan med Specification by Example är ju den ökade kravförståelsen, och som en mycket positiv bieffekt får man exekverbara specifikationer som verifierar att systemet gör rätt.

Följande tre steg behövs:

1. Skriva ett eller flera exempel som specificerar förändringen
2. Få till en teknisk infrastruktur som automatiskt kan verifiera att systemet uppför sig enligt exemplen
3. Införa förändringen i systemet.

1. Exempel som specificerar förändringen

Börja med att ta fram ett, eller kanske flera, exempel. Gäller det en bugg som ska rättas handlar exemplen om hur systemet borde uppträda om inte buggen fanns. Gäller det en ny funktion är exemplen en beskrivning av den nya funktionen. Dessa exempel tas (i idealfallet) fram av verksamheten och IT gemensamt.

Det kan kanske vara på sin plats med ett konkret exempel på hur ett exempel kan se ut!

Säg att vi har ett sajt där användarna kan välja att visa innehållet på olika språk. Det finns också ett administrationsgränssnitt där man kan lägga till språk. På sajten finns en meny där de olika språken finns valbara för användaren.

Nu antar vi att det finns behov av en ny funktion där enbart publicerade språk är valbara. Då skulle ett exempel kunna se ut så här:

Scenario: Endast publicerade språk är valbara

Givet att följande språk finns definierade   | Språk  | Publicerat |   | Swedish| Ja         |   | English| Ja         |   | Dutch  | Nej        |

När användaren vill byta språk

Så skall följande språk vara valbara    | Språk   |   | Swedish |   | English |

2. Teknisk infrastruktur

Nu när exemplen är specificerade, är det dags att få till en automatisk test/verifiering av specifikationerna. För detta behöver man sätta upp en teknisk infrastruktur. Det kan ta lite olika lång tid, och tiden det tar ska inte underskattas, men det är en investering som lönar sig!

Här är några punkter att tänka på:

• Det behövs något verktyg som utifrån exemplen kan exekvera systemet (i en .Net-miljö är exempelvis SpecFlow http://www.specflow.org/ ett bra val)
• Ofta kan det behövas vissa modifieringar, sk refaktoriseringar, för att koden i systemet ska möjlig att verifiera automatiskt
• Om det finns kommunikation med andra system behöver man en strategi för hur dessa ska anropas
• Hur testdata ska bli tillgänglig för verifieringen
• Verifieringen ska integreras i den automatiska byggprocessen.

3. Inför förändringen

Nu är infrastrukturen på plats, som verifierar att systemet uppför sig i enlighet med specifikationerna.

Då återstår bara att införa förändringen i koden och lägga till den nya fuktionen!

Och när förändringen är gjord, så kommer de automatiska testerna visa att systemet uppför sig enligt specifikationen.

---

Sammanfattning:

För att komma igång med Specification by Example och BDD, behövs

• En workshop för att hitta konkreta exempel för den nya funktionen
• En teknisk infrastruktur för att få till en automatisk verifiering av exemplen
• Och till sist implementera funktionen

Och nu när du vet hur man kommer igång, återstår frågan, när är rätt tillfälle att börja? Om det kan du läsa i nästa inlägg.

Har du missat vårt blogginlägg om varför du ska arbeta med Specification by Example och BDD kan du läsa det här!

Vill du fördjupa dig ännu mer i ämnet så ladda gärna ner vårt kostnadfria whitepaper om hur dessa verktyg skapar mer lyckosamma IT-projekt.