BDD i .NET med SpecFlow

Vi fick även ett projekt där det passade sig att se om det gick att utveckla på samma sätt som man ofta gör inom Ruby On Rails när det kommer till testningen. Jag har tidigare erfarenhet inom Cucumber så Specflow kändes som ett självklart val. Om dessa båda är helt främmande för dig så kan det egentligen kortfattat sammanfattas som ett gemensamt språk mellan dig och kunden för att beskriva den funktionalitet man håller på att utveckla. Detta språket, som kallas Gherkin, omvandlas sedan till tester som du kan exekvera. Detta underlättar samarbetet med kunden oerhört eftersom vi har ett gemensamt mål och vi vet båda exakt vad som ingår i projektet.

Idéen är att man testar utifrån och in, man kan säga att man försöker i testerna efterlikna en eventuell besökare och de saker han kan göra på webbplatsen. Det går även att skriva testerna på svenska, till exempel så här.

Det finns dock lite meningsskiljaktigheter om huruvida man ska testa från gränssnittet eller om man ska testa från den kod som ligger direkt under, i vårt fall våra Controllers eftersom vi använde ASP.NET MVC 3. För mig kändes det självklart att testa så mycket som bara går, och "mocka" så lite som går. Eftersom vårt uppdrag var att bygga en JSON tjänst och därför inte hade något avancerat gränssnitt, valde vi att även testa även "gränssnittet". Alltså göra riktiga anrop till vår tjänst i testerna (på så sätt kan vi simulera ett verkligt anrop inklusive autenticiering osv). Jag utlovade visst lite lärdomar angående SpecFlow i titeln på detta blogginlägg så här kommer dem:

• SpecFlow kan vara ett oerhört kraftfullt verktyg när det gäller kommunikation mellan kund och utvecklare.
• Språket du använder i SpecFlow, som kallas gherkin, gör att tester är oerhört mkt enklare att författa. Testa BDD om du har svårt att komma igång med TDD.
• Fundera både en och två gånger extra angående om du vill/behöver testa gränssnittet i din applikation. Här ligger nämligen .NET en bra bit efter t.ex Ruby och det kan vara ganska bökigt. Bra bloggpost angående hur man _kan_ lösa det i .NET läses på Steve Sandersons Blog Han har även producerat ett verktyg för att lösa de problem som du förmodligen ganska snart får angående Cross Process Mocking.
• Med en enkel MS-build task kan du se till att en testrapport genereras när du bygger. På så sätt kan man se till att en uppdaterad rapport alltid finns på webbplatsens testserver. På så sätt kan kunden alltid se hur många procent av våra "scenarion" som är klara för tillfället.