08.02.12 | kl. 07:41 | Aktuelt, Prosabladet
Smarte test i en agurketid
En ny måde at teste software på er ved at vinde indpas i udviklerkredse. Filosofien går ud på at sætte domæneeksperterne – dem, der ved, hvordan den udviklede software skal benyttes – til selv at skrive krav i naturligt sprog, som så direkte kan omsættes til automatiserede test.
Et simpelt eksempel kan være: "Hvis brugeren klikker på login-knappen, og feltet 'navn' ikke er udfyldt, så skal systemet give brugeren en fejlmeddelelse." Ved hjælp af et regulært udtryk kan der også udtrækkes parametre såsom tal eller tekst, så testen kan genbruges. I det foregående eksempel kunne det for eksempel være knapper og felters navne, som kunne være variable, så en lang række test kan dannes ud fra samme regulære udtryk. Hver enkelt bid i testen brydes op i individuelle stykker, som kan genbruges og sættes sammen på kryds og tværs.
Naturligt sprog giver bedre software
Det er i al sin enkelthed princippet bag Cucumber, der oprindeligt er et Ruby-miljø til test inden for den metodik, der kaldes Behavior Driven Development (BDD).
– Det er en måde at beskrive, hvad et system skal gøre, i almindeligt sprog, forklarer amerikanske Brian Sletten, som talte om Cucumber på sidste efterårs Goto-konference i Aarhus.
Det handler om at tage udgangspunkt i naturligt sprog, men på en måde, så resultatet kan testes programmatisk. Cucumber er et slags domænespecifikt sprog, et såkaldt 'lille' sprog. Det rammer en balance mellem noget, som alle kan forstå, og noget, som kan omsættes til kode.
– Det gør det nemt for ikke-tekniske mennesker at sige: 'Jeps, det er sådan, systemet skal opføre sig.' Og tekniske mennesker kan tage reglerne og sørge for, at systemet opfylder dem.
Unit test er for teknikere
Brian Sletten var rådgiver på et udviklingsprojekt, hvor metoden blev anvendt. Han oplevede, at det var nemt for udviklerne at omsætte brugerfortællinger, user stories, fra forretningsdelen til Cucumber-test. I Brian Slettens projekt, hvor der skulle bygges en REST-grænseflade til et eksisterende system, blev der opereret med 2.000 scenarier, og hvert scenarie mundede ud i tre til ti sætninger, så det samlede antal test endte på 10.000-20.000, i et projekt på omkring 10.000 linjers kode.
Det skete fortløbende over en periode på 18 måneder, hvor hver iteration i udviklingsprocessen endte med 200 nye scenarier. Den ene del af holdet arbejdede med scenarierne og den andel del med at implementere funktionaliteten. Når holdene samles, ved man, at det er den rigtige funktionalitet, man har arbejdet på. Samtidig støder man på problemer og fejl tidligt i processen.
Til sammenligning er unit test, der har bred anvendelse i udviklingsarbejde, meget kodefokuserede og giver kun værdi, hvis man tester det rigtige, mener Brian Sletten. Man er nødt til at have formåen til at kunne forstå teknikken. Med Cucumber og BDD er det den forretningsmæssige del af projektet, der bekræfter, at systemet gør det rigtige.
Levende specifikationer giver pote
Ole Friis Østergaard, som er udvikler for Aarhus-virksomheden Trifork, benytter også Cucumber i sit arbejde.
– Man tænker på, at det ikke er en test, man skriver, men specifikationer af, hvordan systemet skal opføre sig. Det, man udarbejder med kunden, er user stories. Det er inputtet til BDD-cyklussen. Så nedbryder man det til en række scenarier, som er en række eksemplificeringer af, hvad denne user story egentlig går ud på: Givet, at jeg står på login-siden og indtaster forkert brugernavn eller password, så skal login fejle.
Det giver 'levende' specifikationer, som ender med kode, der kan afvikles.
– Cucumber lyder lidt abstrakt, men det er ret simpel teknologi, der ligger bag.
-
Cucumber-eksempel
I det følgende eksempel beskrives en feature, som et system skal have. Det udmøntes i et scenarie, som i eksemplet nedenfor kan testes med koden nedenfor, hvor visse parametre udtrækkes ved hjælp af regulære udtryk.
Eksemplet her benytter Cucumber-jvm, som er en Java-udgave af Cucumber. Ved hjælp af annotationer i koden omsættes en feature skrevet i næsten-naturligt sprog til automatiserede test. Koden bag de enkelte dele af scenariet kan genbruges i andre scenarier.
Feature: Daily car maintenance
Cars need maintenance
Scenario: Fuelling
Given a car with 10 litres of fuel in the tank
When you fill it with 50 litres of fuel
Then the tank contains 60 litres
@Feature(value = "CarMaintenance.feature")
public class FuelCarTest {
private Car car;
@Given("^a car with (\\d*) litres of fuel in the tank$")
public void createCar(int initialFuelLevel) {
car = new Car(initialFuelLevel);
}
@When("^you fill it with (\\d*) litres of fuel$")
public void addFuel(int addedFuel) {
car.addFuel(addedFuel);
}
@Then("^the tank contains (\\d*) litres$")
public void checkBalance(int expectedFuelLevel) {
int actualFuelLevel = car.getFuelLevel();
assertThat(actualFuelLevel, is(expectedFuelLevel));
}
}
Eksemplet stammer fra prosa.dk/link/624.
-
Cucumber, BDD og TDD
Behavior Driven Development – softwareudvikling, som drives frem af krav til programmets opførsel – er en softwaremetodik, der har sit ophav i Test Driven Development, hvor udviklingen starter med at skrive test til systemet. I BDD er vægten forskudt til at handle om systemets opførsel i en bredere forstand end blot at teste en bestemt kodestump.
Cucumber er oprindeligt udviklet til Ruby, men findes også til Java, .Net og mange andre miljøer.
PRINT
