Testdriven och lättrörlig utveckling har länge varit populärt. Nu går trenden mot en mer pedagogisk metodik. Den kallas beteendedriven utveckling och har två stora fördelar:
För det första blir det betydligt enklare för övriga utvecklare att förstå programmets intention.
För det andra blir det enklare att definiera vad objektet ska göra. Att först skriva testspecifikationer driver på ett tydligt sätt designen av objektet.
– Programmering och kod handlar väldigt mycket om kommunikation – kod läses fler gånger än den skrivs, säger Marcus Ahnve, systemutvecklare och Sverigeansvarig på konsultföretaget Thoughtworks.
– För många som arbetat med testdriven och lättrörlig systemutveckling blir beteendedriven utveckling ett naturligt nästa steg, säger Marcus Ahnve.
Beteendedriven utveckling, som namngavs och definierades 2006 av utvecklargurun Dan North, tog sin början i att några utvecklare ville kommunicera bättre kring själva testprocessen. Därmed började de namnge sina programtester på ett tydligare sätt.
Från att tidigare exempelvis kallat en testmetod ”testAddition” skrev de i stället ”testOnePlusOneShouldEqualTwo”, vilket gjorde att intentionen med testet blev tydligare. Det innebar att när ett test fallerade avslöjade testmetodnamnet snabbt vad som inte fungerade, vilket beteende testet hade.
I stället för att prata om att dela upp koden i enheter, ett begrepp som kan tolkas på oändligt många olika sätt, talar utvecklare om att koden är uppdelad i beteenden.
Dan Bergh Johnsson, utvecklare på Omegapoint, berättar att det finns stora vinster med beteendedriven utveckling.
– Jag har märkt av en stor produktivitetshöjning på grund av att beteendedriven utveckling införts i utvecklingsprojektet. Detta eftersom en allmän förvirring runt terminologin kunnat undanröjas, säger han.
Dan Bergh Johnsson berättar också att beteendedriven utveckling egentligen är en ny term på en teknik som redan finns, det handlar om att byta fokus från teknik till problemlösning. Vad applikationen löser snarare än hur den gör det.
– Man kan säga att beteendedriven utveckling är testdriven utveckling plus domändriven design, säger Dan Bergh Johnsson.
Beteendedriven utveckling blir alltmer populärt på grund av att utvecklare lär sig vikten av att fokusera på själva problemställningen.
– Vi programmerare har länge förstått vikten av att bygga system rätt. Nu fokuserar vi också på att bygga rätt system, säger Dan Bergh Johnsson.
Bäst passar beteendedriven utveckling för de företag som har komplexa utvecklingprojekt med avancerade affärsmodeller. Orsakerna är flera.
– Beteendedriven utveckling ser till att systemet hänger ihop och ger möjlighet att uttrycka krav på ett tydligt sätt, säger Dan Bergh Johnsson.
”Egentligen tillför beteendedriven utveckling inte särskilt mycket nytt, men utvecklare ska absolut inte förkasta beteendedriven utveckling som samma sak som testdriven utveckling bara för det. Genom att använda en annan vokabulär och ett bättre namn lyfts fokus från test till beteende”, skriver Emil Gustafsson, utvecklare på svenska Microsoft, på sin blogg Cellfish.
”Därmed är sannolikheten för att den som börjar med beteendedriven utveckling gör rätt från början större än för den som börjar med testdriven utveckling eftersom risken för missförstånd är mindre.”
Han får visst medhåll från Dan Bergh Johnsson.
– Jag håller med om själva essensen, men måste samtidigt säga att utvecklarbranschen saknat just fokus på förståelse för vad systemet gör, inte bara hur det görs.
Test- och beteendedriven utveckling är metoder för att genom korta iterationer utveckla program. Varje iteration börjar med att skapa ett test som fallerar, därefter modifierar utvecklaren koden så att testet går igenom.
Metoden är ett sätt att bryta ner problemet i små hanterbara bitar, men också att översätta abstrakta krav till att bli mer konkreta.
Enligt Behaviour-driven.org ska beteendedriven utveckling ligga till grund för att affärsprocesser och teknik använder samma terminologi och att alla system ska tillföra identifierbart värde till affärsprocesserna
