Een iets uitgebreidere samenvatting van 'self testing code' is dat je deze 'knop' realiseert door in een code naast de applicatiecode ook test code op te nemen. Deze test code roept de applicatiecode aan, en controleert dat deze de verwachte output krijgt. Hierbij is ook het doel dat er een hoge 'code coverage' haalt, typisch een line coverage van 80% in onze opleiding. Maar de afspraak hierover verschilt per bedrijf, en is ook afhankelijk van de complexiteit van de codebase (die - bij DDD aanpak - als het goed is vooral afhangt van de complexiteit van het onderliggende domein...). De vereiste code coverage hangt ook af of de codebase een monoliet is, of een microservices architectuur (MSA) heeft. Bij die laatste krijgen integratie testen meer belang en unit tests wat minder, en is code coverage minder van belang (want bij integratie tests is het geautomatiseerd bepalen van code coverage onmogelijk, of in ieder geval ingewikkelder/nog niet standaard).

Hoe dan ook, de interne werking is dus:

Figuur 2: Intern onderscheid tussen test code (grote O 1) en (vangt de 'inherente' complexiteit conform DDD)

Net als TDD gaat BDD een stap verder dan enkel 'self testing code', want BDD is ook 'test driven'. Door eerst de test code te schrijven, denk je meteen vanuit 'client' kant aan welke interface je methode moet hebben, hoe je deze aanroept, en wat deze teruggeeft. Deze 'HOE roep ik het aan?' zit meer aan de WAT kant: "WAT is de interface", omdat de echte 'hoe' kant is: 'Hoe implementeer ik de code zodat deze daadwerkelijk het verwachte resultaat' teruggeeft. TDD grondlegger Kent Beck (van het Agile Manifesto) noemt dit in zijn article 'Canon-TDD' (2022) de 'Interface/Implementation Split':

"The first misunderstanding is that folks seem to lump all design together. There are two flavors:

1. How a particular piece of behavior is invoked.
2. How the system implements that behavior."

BDD -> Geen unit maar integratie tests!

BDD richt zich primair op integratie- en end-to-end tests die het gewenste gedrag valideren over componentgrenzen heen. Unit-tests zijn nuttig, maar niet het doel van BDD.

The Three Amigo's

Figuur 1: The three amigo's en het BDD proces met 3 stappen+1(van Pluralsight)

"The 'Three Amigos' is a meeting that takes user stories and turns them into clean, thorough Gherkin scenarios. It involves three voices (at least):

• The product owner
• The tester
• The developer

https://johnfergusonsmart.com/wp-content/uploads/2017/11/iStock-147318638-1024x683.jpg

Figuur 2: The three amigo's, niet per se 3, niet per se Spaans, maar wel per se >=3, divers en onderling vriendschappelijke omgang :)

BDD: 'Executable specifications' en synonieme acro's voor BDD

Gherkin is the most commonly used plain-text language for writing executable specifications in Given-When-Then-And-But steps. These scenarios are commonly saved as .feature files.

Feature: Users should be able to book appointments.

Scenario: A user wants to book an appointment.

Given a user has booked an appointment

When the booking status is timed out

Then the appointment will be not confirmed

Bron: 'What are executable specifications?' - Cucumber.io blog, 7-2-2019

... "BDD aims to express requirements unambiguously, not simply create tests. The result may be viewed as an expression of requirements or a test, but the result is the same. Acceptance tests record the decisions made in the conversation between the team and the Product Owner so that the team understands the intended behavior.

There are three alternative labels to this detailing process:

• Behavior Driven Design (BDD)
• Acceptance Test–Driven Development (ATDD)
• Specification by Example (SBE)

Bron & ©: Scaled Agile, Inc.

Lesvragen

Behandelen opgekomen studentenvragen n.a.v. huiswerk of behandelde theorie. Als er geen vragen zijn, dan staan we even stil bij deze vragen:

1. Kun je in algemeen zowel TDD als BDD doen in een project, of moet je kiezen?
2. Welke CDMM checkpunten zijn relevant voor BDD?
3. Voor Java is er Cucumber, voor .NET is erSpecFlow of ReqNRoll, maar welke taal gebruik je wel in beide voor BDD?
4. Wat is een test suit? Heeft een applicatie een testsuite?
5. Het Gherkin voorbeeld op de pagina toont één feature met één scenario. Is dit typisch, of horen bij één feature vaak meer scenario's, of bij één scenario meerdere features?

Quiz

Check je kennis over BDD met onderstaande korte multiple choice toets.

Leerdoelen

Check met onderstaande leerdoelen of je de behandelde stof begrepen hebt en toetsvragen kunt beantwoorden.

• Je kent de relatie van BDD met TDD, DDD en Agile/DevOps
  • met o.a. relevante begrippen als Ubiquitous Language, test-first, red-green-refactor, AAA pattern, given-when-then en collaborative development
• Je kent de BDD three amigo's, en de 3 stappen van het iteratieve BDD proces
• Je kent 2 andere namen van BDD, en kunt deze uitleggen
• Je kent de term 'self testing code' en het onderscheid tussen .feature files, glue code en applicatie code en de talen/standaarden die hier achterin zitten
• Je kunt de verhouding uitleggen tussen BDD test scenario's, test cases en suites met user stories en acceptatiecriteria uit Scrum
• Je kent de test pyramide, het belang van de verschillende soorten testen hierin en de link met BDD
• Je kunt op basis van een tutorial een project met werkende en relevante BDD tests opstellen m.b.v. Cucumber of Specflow (ReqNRoll)

Bronnen

-- Beck, K. (1-12-2023) Canon TDD - Software Design: Tidy First? Substack.com. Geraadpleegd september 2024 op https://tidyfirst.substack.com/p/canon-tdd -- Fowler, M. (1 mei 2014) Self Testing Code martinfowler.com Geraadpleegd september 2024 op https://martinfowler.com/bliki/SelfTestingCode.html -- Cucumber.io (z.d.) What are executable specifications? Geraadpleegd september 2024 op https://cucumber.io/blog/hiptest/what-are-executable-specifications/ -- Scaled Agile (z.d.) Behavior-Driven Development (BDD) Geraadpleegd september 2024 op https://scaledagileframework.com/behavior-driven-development