BDD/Gherkin. Een introductie

Transcriptie

1 BDD/Gherkin Een introductie

2 Organisatie SYSQA B.V. Pagina 2 van 10 Inhoudsopgave 1. Inleiding BDD Gherkin BDD-Tools Voordelen Benodigde kennis en vaardigheden Nadelen Literatuurverwijzingen... 10

3 Organisatie SYSQA B.V. Pagina 3 van Inleiding Met de opkomst van Agile software-ontwikkelmethoden is niet alleen de manier van ontwikkelen veranderd, maar ook de manier van het testen. Binnen Agile komen de requirements, het functionele ontwerp en de code in verschillende iteraties geleidelijk tot stand. Dit betekent dat de traditionele (lineaire) aanpak van het voorbereiden en specificeren van testgevallen en vervolgens het ontwikkelen van testscripts steeds lastiger wordt. De uitdaging is om het testen samen met het gehele team op te pakken en om het testen zo vroeg mogelijk in het proces al uit te voeren. Verschillende fenomenen zoals Test-driven Development (TDD), Behaviour-driven Development (BDD) en Acceptance Test-driven Development (ATDD) spelen hierop in en zorgen ervoor dat het testen beter op Agile aansluit. Voor alle drie de aanpakken geldt dat er eerst testgevallen worden gemaakt en (Unit)tests worden uitgevoerd, waarna er pas wordt ontwikkeld. Acceptance Test-driven Development (ATDD) faciliteert het schrijven van acceptatietests op basis van de requirements. Vervolgens wordt er ontwikkeld op basis van deze acceptatietests. Behaviour-driven Development (BDD) faciliteert dat er functionele testgevallen worden opgesteld die door alle teamleden begrepen worden. Tenslotte is Testdriven Development (TDD) een ontwikkelmethode waarbij de ontwikkelaar eerst unit-tests schrijft, voordat hij gaat coderen. In deze introductie wordt een korte inleiding gegeven op het gebied van Behaviour-driven Development (BDD). Een introductie Acceptance Test-driven Development (ATDD) en Testdriven Development (TDD) zijn tevens beschikbaar.

4 Organisatie SYSQA B.V. Pagina 4 van BDD Behaviour Driven Development (BDD) is geen nieuw framework of een compleet nieuwe methodiek voor software development. Het is een collectie van bestaande technieken die gericht is op het opstellen van duidelijke testcases die door alle teamleden worden begrepen. Deze bestaande technieken zijn voornamelijk afkomstig van Test Driven Development (TDD) en domain driven design/development. BDD richt zich niet op het technisch aspect (zoals TDD) maar op het gedrag van het systeem. BDD heeft als doel om de business- en softwareontwikkeling tot een gezamenlijk begrip te laten komen over het gewenste gedrag van software. Anders verwoord, het probleemdomein (business) en het oplossingsdomein (softwareontwikkeling) komen bij goed gebruik van BDD dichter bij elkaar te liggen. De ontwikkelaar definieert samen met de tester en product owner de testset voor de te ontwikkelen functionaliteit. Na het definiëren van de testset moet de ontwikkelaar de testset opnemen in de unit test voordat de functionaliteit gebouwd gaat worden. Deze testen zullen falen aangezien de functionaliteit nog niet is gebouwd. Na deze stap gaat de ontwikkelaar de functionaliteit bouwen zodat de test slaagt. Bron: De taal die gebruikt wordt voor het maken van testgevallen in BDD is Gherkin. In hoofdstuk 3 zal er verder over Gherkin geschreven worden. Voor het ontwikkelen en uitvoeren van testen zijn diverse (open source) tools beschikbaar, zoals Cucumber, Jbehave, Specflow, Calabash, Cbehave, en Behat. Cucumber en Jbehave zijn de bekendste. In hoofdstuk 4 wordt kort op de tools ingegaan.

5 Organisatie SYSQA B.V. Pagina 5 van Gherkin Gherkin is een schrijftaal die wordt gebruikt voor het maken van testgevallen in BDD. De ontwikkelaar is in staat om functionele testcases, geschreven in Gherkin, op te nemen in de unit testen. Voordeel van Gherkin is dat de taal dusdanig eenvoudig is dat deze na een korte introductie te lezen en te begrijpen is door alle teamleden, inclusief de business vertegenwoordigers. Bijkomend voordeel is dat bouwer en tester dezelfde taal spreken zodat ze kunnen afspreken wie wat test. Gherkin kan al gebruikt worden tijdens het opstellen van systeemrequirements. Hierdoor heb je één manier van formuleren over de hele ontwikkelketen (requirements, unit-testen, functionele testen, regressie, enz.). Een bijkomende voordeel is dat als de requirements geschreven zijn in Gherkin dat je dit een op een kan gebruiken als testscript. Syntax Gherkin beschrijft de gedrag van het systeem door middel van de syntax Given, When, Then, And en But. De Given beschrijft de uitgangsituatie, de When beschrijft de actie of trigger en de Then beschrijft het resultaat. Indien er meerdere uitgangsituaties, acties of resultaten zijn moet de AND gebruikt worden. Als je duidelijk wilt maken dat bepaalde dingen niet aanwezig moeten zijn gebruik je de BUT. Voorbeeld Scenario: bestel koffie met suiker uit de automaat. Given: Water is beschikbaar. AND: Koffie is beschikbaar. AND: Suiker is beschikbaar. When: Koffie met suiker wordt besteld. Then: Koffie met suiker wordt geleverd. BUT: Koffie heeft geen melk. De scenario s kunnen geschreven en gevalideerd worden zodra de user story bekend is. Indien de systeemrequirements opgesteld worden in de Gherkin schrijftaal moeten de user story s met de bij behorende Gherkin scenario s in ieder geval gereed zijn voor de start van de sprint.

6 Organisatie SYSQA B.V. Pagina 6 van BDD-Tools Zoals eerder beschreven zijn er voor BDD diverse tools beschikbaar. In dit hoofdstuk een korte beschrijving van de tools. De BDD tools die op de markt zijn hebben ieder een eigen specialisme. De ene is gericht op Java en de andere weer op PHP. Er zijn tools die meerdere talen ondersteunen. Een daarvan is Cucumber. Dat wil niet zeggen dat Cucumber de beste tool is. Cucumber is wel een van de bekendste en waarschijnlijk ook 1 van de meest gebruikte. Het is niet mogelijk om nu te zeggen dat als je een Java Framework hebt, je beter Jbehave of Cucumber kunt gebruiken. Elke opdracht en omgeving is anders. Test de tools aan jullie behoefte op dat moment. Hieronder een lijst met een aantal tools en op welk framework het is gebaseerd: Cucumber (Ruby framework) Behat (PHP framework) Behave (Python framework) Jbehave (Java framework) Cbehave (C. framework) Jasmine (JavaScript framework) Concordion (Java framework) Specflow (.Net framework) Cucumber Cucumber is een van de meest bekende en gebruikte BDD tools. Cucumber is een Ruby gebaseerde tool dat functionele specificaties, beschreven in simpele tekst, kan uitvoeren als geautomatiseerde test. Cucumber kan gebruikt worden met Ruby, Java,.NET, Flex of web applicaties en ondersteund door rond de 30 gesproken talen. Cucumber is een breed inzetbare tool, maar zoals altijd is het van belang om een goede toolselectie uit te voeren om te garanderen dat de best passende tool gekozen wordt. Er is een studiedocument voor het opdoen van kennis over Cucumber beschikbaar bij SYSQA. Selenium De meesten tools, waaronder ook Cucumber, kunnen goed overweg met Selenium. Op de site staat het opzetten van BDD in Selenium goed beschreven. Calabash Calabash is een open source tool en geeft de mogelijkheid om geautomatiseerde tests te schrijven en uit te voeren voor mobile applicaties. Calabash ondersteunt Andriod en ios apps. Calabash kan goed samenwerken met Cucumber en kan vergeleken worden met Selenium WebDriver

7 Organisatie SYSQA B.V. Pagina 7 van Benodigde kennis en vaardigheden Om Gherkin goed te gebruiken heb je als tester specifieke kennis of vaardigheden nodig, namelijk: Proces- en systeemkennis van het domein; Kennis van Gherkin methode; Analytische vaardigheden; Je neemt niets als vanzelfsprekend aan, maar je stelt de juiste vragen zoals: Wat wordt er nu echt gevraagd? Is dit wel echt zo? Waar in het systeem wordt het gebruikt? Waarom is dat nodig? Hoe werkt dat? Kunnen beperken tot wat nodig is om het doel te bereiken; Kennis van en in staat zijn om requirements te eliciteren. Om Gherkin te introduceren bij het team en business heb je als tester overtuigingskracht nodig. De business is niet gewend om requirements op deze manier te krijgen en zijn vaak bang voor veranderingen. Naast de business moeten ook de ontwikkelaars overtuigd worden. Ontwikkelaars voelen vaak de pijn niet en zien testen als een last. De tester moet het testen sexy maken. Ontwikkelaars willen ontwikkelen, zijn hier goed in en willen niet graag testen. Indien de ontwikkelaar Gherkin gaat gebruiken bij het maken van de unit testen doet hij/zij wat hij leuk vindt, namelijk ontwikkelen. Goede argumenten en voorbeelden helpen bij het accepteren van Gherkin door de business en teamleden. Voorbeelden zijn: Bugs worden eerder ontdekt; Kwaliteit van opgeleverde code wordt verhoogd; Sprints worden beter voorspelbaar; De gemaakt unit test blijft begrijpelijk in de toekomst, ook voor anderen; Proces verbetering verdien je terug in tijd en het verhoogt het werkplezier van de teamleden; Systeemrequirements worden gemaakt voordat de code geschreven is; Minder documentatie nodig, één document wordt gebruikt voor zowel requirements, bouw als test. De rol van de tester verandert door het BDD toe te passen. In plaats van reactief elke sprint te toetsen op kwaliteit kan er nu pro-actief kwaliteit ingebouwd worden. Kijkend vanuit het perspectief van testvolwassenheid, is BDD een hoog volwassen aanpak (prevention-oriënted fase). De tester is met recht tevens een ontwikkelaar te noemen.

8 Organisatie SYSQA B.V. Pagina 8 van Voordelen Het gebruik maken van Gherkin in een agile omgeving heeft de volgende voordelen: Alle teamleden spreken dezelfde taal, hierdoor is er minder kans op miscommunicatie. Ontwikkelaars kunnen de testcases eenvoudig omzetten naar unit testen met behoud van de Gherkin syntax. Hier zijn zelfs (open source) tools voor, bijvoorbeeld Cucumber en Jbehave. Systeemrequirements kunnen direct in Gherkin-stijl geschreven worden, omdat de manier van schrijven voor alle teamleden, maar ook de business, te begrijpen is. Het opstellen van Gherkin-stijl testcases bespaart tijd. Testcases in Gherkin zijn op een logisch niveau geschreven in plaats van gedetailleerd uitgeschreven testcases. Indien de requirements in Gherkin zijn geschreven kan het een op een gebruikt worden voor het uitvoeren van de test. Doordat testvoorbereiding eerder klaar is dan oplevering van functionaliteit kan de tester de Product Owner ondersteunen bij het opstellen van de requirements. Hierdoor wordt je als tester nog meer betrokken bij het ontwikkelproces en stijgt het aanzien en de toegevoegde waarde van de tester bij het team en de business. Doordat de ontwikkelaar in de bouwfase al de testen klaar heeft worden bugs eerder gevonden.

9 Organisatie SYSQA B.V. Pagina 9 van Nadelen Het gebruik maken van Gherkin heeft de volgende nadelen: Proces- en systeem kennis is vereist; BDD is een scherp mes, bij verkeerd gebruik doe je meer kwaad dan goed; Indien de scenario s eenduidig en geverifieerd zijn door de drie belanghebbende (product owner, ontwikkelaar en tester) is de kans groot dat het systeem niet gebouwd wordt zoals verwacht. Mochten de scenario s te high level zijn dan is er zelfs een risico dat er dingen ontbreken of niet getest worden met alle gevolgen van dien. Het team moet volwassen zijn, vaardige teamleden die op elkaar zijn ingespeeld. Gherkin is eenvoudig te leren. Nieuwe medewerkers kunnen dit snel onder de knie hebben. Toch kost het inwerken van nieuwe mensen meer tijd. Dit komt omdat nieuwe mensen over het algemeen niet weten hoe het te testen proces en systeem in elkaar zit. De testscripts die elke stap tot in detail beschrijft zijn namelijk niet aanwezig. De business moet de Gherkin-schrijfwijze ook accepteren, als je de systeemrequirements éénmalig wil vastleggen in Gherking

10 Organisatie SYSQA B.V. Pagina 10 van Literatuurverwijzingen 1. Haring, Ronald "Behaviour Driven development: Beter dan Test Driven Development". Java Magazine (February 2011)