Lesprogramma

1. Demonstratie web rapportages van (evt. deels) geautomatiseerde BDD tests

De docent geeft een demonstratie van rapportage mogelijkheden met Cucumber (zie Bijlage A onderaan voor stappen).

notitie

Vertaling van hoofdstuk 3.6 uit BDD in Action (Smart J.F., 2014)

Als een functie eenmaal is geïmplementeerd, moet je in staat zijn om de testen te draaien en te zien dat er acceptatiecriteria tussen de falende criteria slagen. Wanneer je praktijken zoals BDD toepast, vertelt het resultaat je meer dan alleen dat je applicatie voldoet aan de bedrijfsvereisten. Een acceptatietest die slaagt is ook een concrete maatstaf voor vooruitgang.

Een geïmplementeerde test slaagt of faalt. In het ideale geval, als je alle acceptatiecriteria voor een functie hebt geautomatiseerd en succesvol uitgevoerd, kun je zeggen dat de functie klaar is voor productie.

De staat van de testen geven een duidelijke indicatie van kwaliteit en waar de applicatie zich bevindt in het ontwikkelproces.

De verhouding van succesvolle testen vergeleken met het totale aantal gespecificeerde acceptatiecriteria geeft vervolgens een goed beeld van de hoeveelheid werk die er tot nu toe is verzet en hoeveel er nog moet gebeuren.

Door het aantal voltooide geautomatiseerde (acceptatie)testen af te zetten tegen het aantal nog uit te voeren testen krijg je een idee van de vooruitgang die je in de loop van de tijd boekt.

Als je de testen in de verhalende stijl schrijft, komt er nog een voordeel naar voren. Elke geautomatiseerde acceptatietest wordt gedocumenteerd als een uitgewerkt voorbeeld van hoe het systeem kan worden gebruikt om aan een bepaalde bedrijfsbehoefte te voldoen. En potentieel worden de uitgewerkte voorbeelden zelfs geïllustreerd met screenshots die onderweg zijn genomen.

2. Beoordelen van elkaars rapportage

Vergelijk onderling eens wat de rapportage voor inzicht geeft en houdt dit tegen de criteria aan van een executable specification:

• Compleetheid, alle acceptatiecriteria gedekt (happy en unhappy path) => slagend?
• Herhaalbaarheid, scenario's met concrete voorbeeld gegevens herkenbaar voor stakeholder/actor
• Minimaal, set van scenario's om minimaal al de criteria af te testen.
  • of zijn er ook overbodige scenario's die dingen dubbel verifieren?
  • of zijn er ook criteria die niet geraakt worden?
• Herleidbaar, scenario's zijn herleidbaar naar concrete voorbeelden (op basis van nummer en Gherkin tag?)
• Syntax en grammatica, voldoet het aan de eisen van goede Gherkin?
• Herbruikbare stap definities en zinnige Cucumber Expressions toegepast?

Voor alle stap definities kijk of deze voldoen aan de eisen van kwalitatieve code. Dingen om op te letten:

• Keep it DRY (bijvoorbeeld niet dezelfde automatisering herhalen)
• zorg met cucumber expressions ervoor dat concrete data variabel is (parameter)
• Personas moeten als variabele ingelezen worden om bijbehorende data op te halen (eventueel uit persistentie/database)
• State wordt opgeslagen als attribuut in de stepdefinitions
• Vermijd zoveel mogelijk interne (voor)kennis in de glue code
• Vermijd dat alleen het aanroepen van (wanneer) stappen in een bepaalde volgorde tot het juiste resultaat zal leiden

In bijlage A hieronder nog de stappen om zelf rapportage aan de praat te krijgen met ClueCumber. Dit ook ter referentie tijdens het [PEXE] Project.

Denk na deze les aan het huiswerk voor SolExp (Solution Exploration) komende maandag! SoEx is het vervolgvak van DoEx (en TeEx).

Bijlage A: Details BDD Rapportage demo

Bijlage A: Configuratie van BDD Cucumber coverage rapportage

Hieronder beschrijving van het eerst configureren dat er json output (A.1). En daarna (in A.2) het configureren van ClueCumber om uit deze json een mooi web rapport te genereren, die je WEL aan business stakeholders kan laten zien (in tegenstelling tot de output van tests in je IDE console).

info

NB De content van deze uitklapbalk komt niet op de toets. We focussen in de toets meer op inherent complexity van domeinen en analyse methodes daarvan. Minder op accidental complexity (zoals het in DDD jargon heet), zoals goede configuratie van test frameworks en rapportages. Maar ook dit soort details zijn van belang om goed te krijgen voor een succesvol project en product.

"Essential complexity is caused by the problem to be solved, and nothing can remove it; if users want a program to do 30 different things, then those 30 things are essential and the program must do those 30 different things." - Fred Brooks (1975) volgens Wikipedia.

A.1 Configuratie genereren rapportage door Cucumber framework

Configureer allereerst dat Cucumber een .json (resultaat-) bestand produceert voor de test suite. Hiervoor kan je de ConfigurationParameter(PLUGIN_PROPERTY_NAME) uitbreiden met: json:target/cucumber-report/cucumber.json

Zie voor de locatie van het RunCucumberTest bestand les 3 voorbereiding sectie 2.2

@Suite
@IncludeEngines("cucumber")
@SelectClasspathResource("features")
@ConfigurationParameter(key = PLUGIN_PROPERTY_NAME, value = "pretty, " +
        "json:target/cucumber-report/cucumber.json")
public class RunCucumberTest {}

Het is mogelijk ook een HTML rapport te genereren met dezelfde annotatie, door in het value attribuut een 2e target toe te voegen: html:target/cucumber-report/cucumber.html.

Dan is dit het resultaat:

@Suite
@IncludeEngines("cucumber")
@SelectClasspathResource("features")
@ConfigurationParameter(key = PLUGIN_PROPERTY_NAME, value = "pretty, " +
        "json:target/cucumber-report/cucumber.json, " +
        "html:target/cucumber-report/cucumber.html")
public class RunCucumberTest {}

A.2 Cluecumber rapportage op basis van Cucumber json rapport

Een mooier rapport is bijvoorbeeld te genereren met de Cluecumber plugin.

Het enige dat deze als input nodig heeft is het json Cucumber rapportage bestand. Een voorbeeld configuratie op basis van bovenstaande ConfigurationParameter instelling ziet er als volgt uit binnen de pom.xml <build><plugins> sectie:

<build>
    ...
    <plugins>
        ...
        <plugin>
            <groupId>com.trivago.rta</groupId>
            <artifactId>cluecumber-maven</artifactId>
            <version>3.1.0</version>
            <executions>
                <execution>
                    <id>report</id>
                    <phase>post-integration-test</phase>
                    <goals>
                        <goal>reporting</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <sourceJsonReportDirectory>${project.build.directory}/cucumber-report</sourceJsonReportDirectory>
                <generatedHtmlReportDirectory>${project.build.directory}/generated-report</generatedHtmlReportDirectory>
            </configuration>
        </plugin>
    </plugins>
</build>