Cucumber, JBehave eller FitNesse

FitNesse, JBehave och Cucumber har alla gemensamt att de låter oss skriva automatiska tester i form av tabeller eller i naturligt språk på format Given, When, Then. Dessa tester utlovar att de dels kan ersätta kravspecen och dels öppna upp systemets funktion och natur mot andra än dem som pratar programmeringsspråk flytande.
cucumber2013-4k
Ska man då plugga in FitNesse, JBehave eller Cucumber i sin Continuous Delivery Pipeline? Vi undersökte saken nyss på en av våra kompetensutvecklingsdagar. Mats Lidell, som dagligen jobbar med FitNesse, var först ut och hade förberett dagens första timmar att handla om FitNesse.

FitNesse är centrerat kring sin Wiki, där man beskriver krav i tabellform. En styrka med FitNesse är definitivt Wikin, där man uppmuntras att omge de exekverbara kraven med beskrivande och mer ostrukturerad information, på så vis kan Wikin bli en lättillgänglig och naturlig plats att beskriva systemets krav och funktion.

Mats visar hur man startar Wikin, skriver in krav och när han trycker på knappen “Test” och de olika stegen färgmarkeras i Wikin vartefter testerna exekveras, hummar vi åhörare imponerat.

När vi sätter igång med övningarna får några av oss ett felmeddelande när vi bygger med fitnesse-launcher-maven-plugin:

[ERROR] Failed to execute goal uk.co.javahelp.fitnesse:fitnesse-launcher-maven-plugin:1.3.0:set-up (fitnesse-tests) on project fitnesse-integration-test: Execution fitnesse-tests of goal uk.co.javahelp.fitnesse:fitnesse-launcher-maven-plugin:1.3.0:set-up failed: An API incompatibility was encountered while executing uk.co.javahelp.fitnesse:fitnesse-launcher-maven-plugin:1.3.0:set-up: java.lang.NoSuchMethodError: org.apache.maven.execution.MavenSession.getRepositorySession()Lorg/sonatype/aether/RepositorySystemSession;

Efter gemensam undersökning visar det sig bero på en inkompabilitet mellan fitnesse-launcher-maven-plugin 1.3.0 och Maven 3.1.1. En nedgradering av Maven till 3.0.5 gör att vi kommer vidare.

Det finns en felrapport, och 1.4.0 verkar vara på väg med en fix.

Vi provar på integrationen i vår build pipeline genom att FitNesse kör integrationstester mot Goldenzone som ett byggsteg. Det fungerar bra.

JBehave
Näste man ut i ringen är Christian Karlsson på JBehave. Christian har använt JBehave i ett par skarpa projekt med mycket gott resultat. JBehave är lite mer liknande vanlig integrations- och enhetstest i och med att man skriver sina kravsteg direkt i textfiler enligt speciella regler. Det känns rättframt. Verkligt givande är exemplen som Christian visar från verkliga livet i ett par system där vi får se hur JBehave ser ut när det är fullt utbyggt att täcka de funktionella kraven för ett helt system.

Vi får prova på att göra flera labbar med JBehave. Det flyter på, fungerar bra och bjuder på trevliga aha-upplevelser.

Cucumber
Fredrik Dahlman avslutar med att visa oss Cucumber. Cucumber är mycket likt JBehave, men känns något mer polerat och lättanvänt. Dessutom finns en plugin i Intellij som får Cucumber att se bra ut i editorn. Fredrik har också goda erfarenheter från Cucumber från skarpa projekt.

Vi provar på några övningar även med Cucumber, och konceptet är nästan identiskt med JBehave, men även mycket av FitNesse känns igen.

Build Pipeline
Integrationen i vår build pipeline bygger på samma princip som för alla andra integrationstester, dvs man lägger testerna i en maven-modul och i dess pom konfigurerar man dels så att applikationsservern (via embedded-glassfish-plugin) går igång och applikationen deployas på den i mavens integrationstestfas, sedan konfigurerar man en verktygsspecifik maven-plugin som kör testerna.

FitNesse integrerar vi med fitnesse-launcher-maven-plugin:1.3.0 och JBehave med jbehave-maven-plugin:3.8. Cucumber hann vi inte integrera i pipelinen, men principen borde vara densamma.

Arbetsprocess
Arbetsprocessen skiljer sig inte från den när man utvecklar integrationstester i något annat språk, dvs:

  • Konstruera tester (dokumentera i tabeller eller i naturligt språk på format Given, When, Then)
  • Implementera fixturer, klisterklasser, eller testimplementationer
  • Implementera funktionaliteten som ska testas
  • Verifiera att det funkar
  • Committa

En skillnad mot att skriva tester i ett programmeringsspråk är att källkoden blir läsbar av alla.

Verktygen möjliggör en arbetsprocess där någon annan än en utvecklare, närmast till hands test eller krav, skriver testerna. Implementationen av testerna, när man kopplar texterna och tabellerna till programkod, sker i samband med implementationen av funktionen de testar. I och med att kopplingen, och därmed effektureringen av kravexekveringen sker där, kan de automatiska testerna synkas med implementationen, vilket är ett krav för att Continuous Delivery ska fungera.

Om man väljer FitNesse så sätter man nog upp en server som alltid kör Wikin eftersom hela poängen med Wikin är att tillgängliggöra för dem som inte är vana att använda versionshanteringsverktyg.

För att synka pipeline-bygget med Wiki-innehållet måste man bestämma sig för när ändringarna i Wikin ska commmittas. Antingen committar man nuvarande version av Wikin automatiskt varje gång commit-stage blir triggat i build pipeline eller så gör man commit till en manuell funktion som styrs av den som redigerar wikin, som då också ansvarar för att testerna passerar innan commit. FitNesse lagrar sitt innehåll i textfiler i versionsrepot.

Både Cucumber och JBehave producerar rapporter i t.ex. html som man kan välja att publicera på någon webbsajt, vilket innebär att de kan uppfylla samma funktion att tillgängliggöra som FitNesses wiki gör, så länge man bara läser.

Alla tre verktyg bygger på att man har anledning att förvänta sig att andra än utvecklare kommer att läsa och kanske också skriva testerna. Kan man låta testerna utgöra kraven och alltså ersätta sina kravdokument, då slipper man också hanteringen av kravdokumenten och dessutom att administrera krav-/testtäckningsmatriser.

Summering
Efter att ha ägnat en hel dag åt dessa tre verktyg är kan vi konstatera att alla tre fungerar på ett liknande sätt, där FitNesse skiljer ut sig en smula emedan JBehave och Cucumber mer är som syskon.

FitNesse kräver mer av jobb kring infrastrukturen för att komma till sin rätt i och med Wikin, men har också mer potential just därför.

JBehave har gott om konfigureringsmöjligheter och vinner över Cucumber i en jämförelse vi hittade  med ställningen 30-28. Cucumbers mer välpolerade egenskaper värderades inte å andra sidan. Dött lopp.

Känner du nån du gillar och litar på som kan något av verktygen, så räcker det som övertag för att välja verktyget. Jag som känner tre jag gillar och litar på, som kan sitt respektive verktyg, får därför ingen beslutshjälp alls.

IT Consultant at CAG Edge. Cloud and Continuous Delivery specialist, software developer and architect, Node.js, Java.

Publicerad i Continuous Delivery, Java, Test

Kategorier

WP to LinkedIn Auto Publish Powered By : XYZScripts.com