De senaste åren har jag gått igenom en ”mognadsprocess” när det gäller min inställning till acceptanstester. Tidigare tyckte jag nog bara att detta var något nödvändigt ont som man gjorde för att man måste, men numera har jag insett att bra acceptanstester kan göra underverk för vilket projekt som helst. Jag pratar naturligtvis om automatiserade acceptanstester för att åstadkomma Acceptanstestdriven Utveckling (ATDD).

Särskilt upphetsad är jag över utvecklingen mot acceptanstester som definieras med domänspecifika testspecifikations-språk, DSLs for acceptance testing. Att en icke programmeringskunnig beställare närsomhelst kan titta i och förstå en ständigt körbar specifikation – skriven i termer av den egna verksamheten – tror jag ger honom/henne en enorm känsla av kontroll över systemets alla krav och önskemål. Och antalet missförstånd mellan beställare och utförare kan minska dramatiskt!

Den som har skrivit mest och bäst om domänspecifika språk är nog Martin Fowler. Han har publicerat några artiklar och han håller på att skriva en bok i ämnet. Enligt Fowler är det att lägga ribban för högt om man försöker skapa en DSL som beställaren kan skriva helt på egen hand. Oftast räcker det med att han/hon skapar testerna tillsammans med en utvecklare, bara testerna lätt kan förstås i efterhand, utan en utvecklares hjälp.

Att kunden är ansvarig för att definiera körbara acceptanstester är ju inget nytt i sig. Jag tänker främst på verktyg som Fit och FitNesse, som lämpar sig väldigt bra för kundskrivna acceptanstester när indata och förväntat utdata kan specas i tabell- eller matrisform. Utvecklarna får då hjälpa till med att skriva små ”bryggor” mellan tabellerna och den testade koden. I de triviala fallen är detta en bra lösning, men ofta blir ju användingsfallen svårare än så. Tabellerna kan bli kryptiska för kunden och det kan bli besvärligt för utvecklaren att utveckla bryggorna.

En strategi för att skapa ett DSL för acceptanstestning är att först låta kunden formulera några krav i hans/hennes egen terminologi på ren engelska, och därefter göra så lite modifikationer som möjligt till den syntaxen. Kund och utvecklare tillsammans ändrar endast de språkkonstruktioner som kan göra det svårt för en dator att tolka texten. Man kanske kan behålla 90% av den exakta (engelska) ordalydelsen.
Detta är bara ett exempel på tillvägagångssätt, och resultatet behöver inte vara särsklit likt engelska heller.

Var på skalan mellan kryptiskt datorspråk och vältalig engelska man hamnar beror på hur man prioriterar mellan flera olika faktorer. Till exempel:
*Hur kraftfull behöver DSL:en vara?
*Hur stor del av verksamheten/logiken behöver DSL:en hantera? (Mindre delar –> enklare, men fler DSLer)
*Vilken programmeringskunskap finns hos kunden/domänexperten? Något specifkt språk?
*Hur mycket tid/pengar kan man lägga på arbetet med att skapa DSL:en?

Den viktigaste faktorn för framgång är nog ändå att kunden måste vara förberedd på att vara kontinuerligt delaktig i DSL:ens utveckling och inte bara i själva specandet. En ytterligare förutsättning är att testerna och koden som testas lever i symbios och influeras starkt av varandra. Att försöka skriva ett DSL i efterhand för ett existerande system (utan att ändra det) tror jag skulle vara mycket problematiskt för att inte säga omöjligt.

Jag har tidigare bloggat om ett av mina favoritcitat (japp, Fowler är skyldig till detta också!):

Any fool can write code that a computer can understand
Good programmers write code that humans can understand

Nu skulle jag villja göra ett litet tillägg:
Excellent programmers write tests that customers can understand!

:-)

Här kommer lite rekommenderad läsning om man tycker att det låter intressant med DSL-acceptanstestning:

http://martinfowler.com/bliki/DslQandA.html
http://studios.thoughtworks.com/download_files/DSLs_for_Functional_Testing_ThoughtWorks_Feb08.pdf
http://www.martinfowler.com/bliki/DomainSpecificLanguage.html
http://www.testingreflections.com/node/view/6704