Training Agenda

TDD / BDD

Test-Driven Development is a development practice, not a testing practice — writing the test first shapes the design. Behavior-Driven Development extends TDD toward collaboration: scenarios written in business language that developers, testers, and product owners can all read and validate. This training covers TDD red-green-refactor discipline, BDD scenario writing, and the interplay between them in a real development workflow.

1–2 days On-site, remote, or hybrid Up to 20 participants German or English
What We Cover
Test-first development and behaviour-driven collaboration
Day 1

Test-Driven Development

  • TDD fundamentals: red-green-refactor cycle — disciplined, not dogmatic
  • Writing the failing test first: what it forces you to think about
  • Unit test design: fast, isolated, deterministic, self-describing
  • Test naming: describing behaviour, not implementation
  • Mocking and stubbing: Mockito — when mocks help and when they mask design problems
  • Test doubles taxonomy: dummy, stub, spy, mock, fake
  • Inside-out vs outside-in TDD: London school vs Detroit school
  • TDD with Spring Boot: @SpringBootTest vs @WebMvcTest vs pure unit tests
  • Refactoring safely under test: the green bar as a safety net
  • Common TDD pitfalls: overtesting, brittle tests, testing implementation details
Day 2

Behaviour-Driven Development

  • BDD concepts: the three amigos — developer, tester, business analyst
  • Gherkin language: Feature, Scenario, Given, When, Then — writing readable scenarios
  • Scenario quality: concrete examples vs abstract descriptions
  • Example Mapping: discovering and structuring scenarios before writing code
  • Cucumber integration: step definitions, world object, hooks
  • Living documentation: keeping scenarios in sync with the system
  • Acceptance TDD: writing failing acceptance tests before development
  • BDD at different levels: unit, integration, API, UI — when each makes sense
  • Retrospective: what TDD/BDD changed and what it didn't in practice
Learning Outcomes
What your team walks away with

Developers who practice TDD as a design activity — not just a testing activity — and teams who use BDD scenarios as a shared language between business and engineering.

Book the TDD / BDD training

Hands-on from the first hour — participants write code in the session. Works best as a combined team training with mixed roles.

Get in touch