What is AssertJ-DB?

AssertJ-DB is an extension of the AssertJ assertion library designed specifically for database testing in Java.
It enables developers and testers to write fluent, readable, and chainable assertions directly against relational database content like tables, requests (queries), and changes (insert/update/delete operations).

Unlike traditional database verification methods that rely heavily on manual SQL queries and complex checks, AssertJ-DB allows you to test database states declaratively, in plain Java, improving test maintainability, readability, and developer productivity.

AssertJ-DB works with JDBC-compatible databases such as MySQL, PostgreSQL, Oracle, SQL Server, H2, and more.

It is particularly valuable in unit tests, integration tests, and end-to-end testing where validating the database is a crucial aspect.

Major Use Cases of AssertJ-DB

1. Database State Validation
   Confirm that after performing operations (e.g., creating an order, updating a profile), the database reflects the expected data.
2. Change Tracking Tests
   Validate that a specific number and type of database changes (insert, update, delete) occur after an action.
3. SQL Query Result Assertions
   Test specific queries or stored procedures by asserting the structure and data of the returned result set.
4. Transactional Testing
   Assert the state of tables during or after transactions without writing raw JDBC code.
5. Data Migration Verification
   When migrating data from one schema/version/system to another, assert that the resulting tables match expected conditions.
6. CI/CD Pipeline Testing
   Integrate AssertJ-DB tests into automated pipelines to ensure database consistency after deployments.

How AssertJ-DB Works – Architecture Overview

Core Components:

• Table:
  Represents the full content of a specific database table at a point in time.
• Request:
  Represents the result of executing a custom SQL query.
• Changes:
  Captures and asserts differences in database state over time (e.g., between two operations).
• Assertions API:
  Fluent Java assertions for columns, rows, values, and changes.

How It Works:

1. Connection Setup
   AssertJ-DB connects to the database using JDBC.
2. Snapshot
   It captures snapshots of table states or query results.
3. Comparison & Assertions
   Developers write fluent assertions comparing expected values with actual database contents.
4. Change Tracking
   Optionally, developers can capture and compare database state before and after actions to assert changes.

Visual Architecture:

+------------------+
| JDBC Connection  |
+--------+---------+
         |
         v
+------------------------+
| Table / Request / Changes |
+------------------------+
         |
         v
+----------------------------+
| AssertJ-DB Fluent Assertions |
+----------------------------+
         |
         v
+---------------------+
| Test Pass / Fail    |
+---------------------+

Basic Workflow of AssertJ-DB

1. Connect to Database
   Use JDBC URL, user, and password to set up the connection.
2. Take a Snapshot
   Capture the current state of a table, a custom SQL query, or database changes.
3. Perform Actions
   Trigger the operations you want to test (e.g., insert data, update records).
4. Capture Changes (Optional)
   Capture new database state if change tracking is needed.
5. Write Assertions
   Use AssertJ-DB fluent API to assert database values, rows, columns, or changes.
6. Run Tests
   Execute tests in your JUnit/TestNG testing framework.

Step-by-Step Getting Started Guide for AssertJ-DB

✅ Pre-requisites

• Java 8 or higher
• JUnit 5 or TestNG installed
• Maven or Gradle build system
• A running database instance (MySQL, PostgreSQL, H2, etc.)

🛠️ Step 1: Add AssertJ-DB to Your Project

For Maven:

<dependency>
  <groupId>org.assertj</groupId>
  <artifactId>assertj-db</artifactId>
  <version>2.0.2</version> <!-- Use latest stable version -->
  <scope>test</scope>
</dependency>

For Gradle:

testImplementation 'org.assertj:assertj-db:2.0.2'

🛠️ Step 2: Setup JDBC Connection

Connection connection = DriverManager.getConnection(
    "jdbc:h2:mem:testdb", "sa", ""
);

(Replace with your database URL, username, password.)

🛠️ Step 3: Create a Table Assertion

Example: Validate Table Content

import org.assertj.db.type.Table;
import static org.assertj.db.api.Assertions.assertThat;

Table table = new Table(connection, "users");

assertThat(table)
    .hasNumberOfRows(2)
    .row(0)
    .value("username").isEqualTo("admin")
    .value("email").isEqualTo("admin@example.com");

🛠️ Step 4: Track and Assert Changes

Example: Validate Changes After an Insert

import org.assertj.db.type.Changes;

Changes changes = new Changes(connection);
changes.setStartPointNow();

// Perform action: insert a user
statement.executeUpdate("INSERT INTO users(username, email) VALUES('john', 'john@example.com')");

changes.setEndPointNow();

assertThat(changes)
    .hasNumberOfChanges(1)
    .change()
    .isCreation()
    .rowAtEndPoint()
    .value("username").isEqualTo("john")
    .value("email").isEqualTo("john@example.com");

🛠️ Step 5: Run Tests

Run the above test class as a JUnit 5 or TestNG test.
✅ You now have strong and readable database assertions inside your Java tests!

Often, when organizations plan and implement an effective test automation strategy, they believe that they are implementing continuous testing. They are wrong.

Test automation is certainly one of the most critical components of continuous testing. But implementing continuous testing begins with a multi-layered test strategy that includes all the types and levels of testing required—including unit, integration, functional, exploratory, and automated. Continuous testing must also have a strategy for incorporating testing throughout the continuous integration pipeline.

Organizations turn to DevOps to increase value and improve the customer experience by maximizing the speed of delivery without sacrificing quality. DevOps delivers by implementing a continuous delivery pipeline, which requires continuous testing.

But just what is continuous testing? The practice goes beyond executing automated tests throughout the software delivery pipeline and providing immediate feedback on the risks associated with a potential release.

Continuous testing requires continuous business and technical risk analysis, as well as process improvement and automation throughout the continuous integration process. Equally critical is developing a culture in which quality is a shared responsibility of every team member. It is based on an approach to managing risk that eliminates testing bottlenecks by improving the effectiveness and increasing the efficiency of your test processes.

Here are four key steps for an effective continuous test strategy, plus what you need to know about each.

1. Streamline the test process
This has three components: focusing on business risk, identifying and mitigating bottlenecks, and optimizing your tests.

The ultimate goal of DevOps and, therefore, the goal of continuous testing, is to mitigate business risk, which is composed of both customer risk and organizational risk.

Customer risk involves understanding which application workflows are most important to the customer and planning your risk-based test coverage accordingly.

Organizational risk involves understanding the complexities of the business climate as well as the product itself. For example, is it critical to be first to market, or is the product health or safety more important? Once the overall business risk is accurately assessed, you should map requirements, application components, and tests to those risks.

It is critical to identify and mitigate bottlenecks; they impede both quality and velocity. Constraints to the test process can be found throughout, from requirements through post-production checkout. Some examples include testers not being included in backlog refinement so they don’t have the opportunity to help build the acceptance criteria, defects not being addressed on a timely basis, automated test suites running too long, and post-production checkouts being done manually.

Optimize your tests
Test optimization, the foundation for an effective automation strategy for continuous testing, is the practice of selecting the right tests that provide the test coverage you need with the fewest number of test cases.

This practice has many applications, from risk-based selection of tests for a full regression suite to choosing tests for targeted testing and regression of new features. It is a dynamic, ongoing process, especially when applied as part of a continuous testing framework. Test optimization should take place prior to automation and must continue throughout the continuous testing process.

The first step here is optimizing the test scope by understanding all integrations involved in critical user workflows—including the technologies employed in those applications (web, mobile, message/API layer, etc.).

Once you have a clear understanding of the test scope, your next step is to optimize the test cases. This includes not only analyzing test cases for their quality and level of detail, but also selecting tests that provide the greatest level of test coverage. Your test suites should be designed to provide the maximum amount of coverage with the fewest number of test cases to increase both quality and velocity.

Test optimization is a dynamic process. Evaluating effectiveness is a critical part of maintaining an optimized test suite. The suite should be evaluated continually to deprecate tests that are no longer needed, address flaky tests, and add new tests based on new features.

2. Automate testing throughout the CI pipeline
Continuous testing requires test automation throughout the delivery pipeline. Test automation increases the speed of deployment and reduces the risk inherent in continuous delivery.

But automation within the continuous testing framework is about more than just developing and maintaining an automated regression suite. In fact, automated regression suites, especially those that run overnight, create bottlenecks in the continuous deployment process. Continuous testing requires a test automation strategy that enhances, rather than impedes, the continuous delivery process.

It is not enough to implement an optimized regression test suite. The automation test strategy must include automated checkpoints at each step in the build process. This begins with unit tests that verify individual pieces of code and component tests to verify key features. Risk-based regression test suites should be customized based on the features you’re currently implementing.

Automated testing continues into production, with post-deployment health checks to ensure the applications are up and running. As a final step, production monitoring should find functional and performance issues before the customer finds them.

Within your continuous testing strategy, test automation must be designed to run efficiently while providing reliable, consistent, reproducible results. Your automation strategy must be well developed and include the test maintenance plan and a schedule of which automated tests should run at specific points along the delivery pipeline.

3. Shift left
To implement a successful continuous testing strategy, it is critical that the team embrace the shift-left tenet of quality engineering, which advocates testing as early as possible in the development process. Quality engineering is the practice of building quality in throughout the process; it starts with development and focuses on preventing defects, rather than finding them. Shifting testing left enables quality engineering and continuous testing.

Test-driven development (TDD), behavior-driven development (BDD), and acceptance test-driven development (ATDD) are all techniques used to “shift left.”

In TDD, developers and testers work together to design the test first, and then develop the code to make the test pass. BDD is TDD with a design focus on customer behavior. ATDD focuses on customer-centric design where the “three amigos”—developers, testers, and product owners—share responsibility for and work together in design sessions.

It’s important to take a shift-left approach to nonfunctional testing as well. Since the root cause of many performance and security defects can be found in design, it’s critical to find defects early, before the design is finalized. When you don’t find those defects until late in the process, they become much more complicated and expensive to fix.

4. Take responsibility for quality
This step is the underpinning of the continuous testing strategy. Unless all team members accept their roles in quality assurance, it will be impossible to successfully implement the other elements.

Taking responsibility for quality requires a shift in mindset that must be led from the top. Education is critical, since each member of your team must understand the nature of his or her role in quality engineering.

New device releases, shifting market expectations, and a perpetual shortage of skilled engineers make spring one of the most demanding periods for software development teams. Rather than simply pushing harder, it is worth taking a step back to assess your DevOps practice and clear out the friction that slows delivery. Below are four concrete areas where a focused clean-up can yield faster releases and measurably better customer satisfaction.

1. Clarify Roles and Responsibilities

DevOps deliberately blurs the traditional boundaries between development, testing, security, and operations—and that flexibility is a feature, not a bug. However, when responsibilities are permanently ambiguous, engineers experience role confusion, accountability gaps open up, and handoffs break down.

As security and networking move earlier into the software development lifecycle (SDLC), every team needs a clear picture of where they plug in. A practical starting point is to schedule what some practitioners call service health reviews: regular, structured meetings where each team discusses the current state of production services, recent wins, and active pain points—including cultural ones. Monthly cadence tends to work well; it is frequent enough to catch drift before it compounds, but not so frequent that it becomes overhead.

• Document who owns each stage of the SDLC before a new project kicks off.
• Distinguish between who is responsible for a task and who is merely consulted (a simple RACI matrix can help).
• Revisit role definitions whenever the team structure or toolchain changes significantly.

2. Sharpen Your Team’s Skill Sets

The blurring of DevOps roles demands a broader and continually refreshed skill set. Automation expertise, cloud-native tooling, security fundamentals, and observability practices are all increasingly expected of engineers across the pipeline—not just specialists. A periodic skills audit helps identify where your team is well-covered and where gaps could become blockers.

Three levers that consistently move the needle on team capability:

• Secure executive buy-in. Training budgets and protected learning time require leadership commitment. Frame the investment in terms of delivery risk and time-to-market rather than abstract professional development.
• Establish a structured mentoring programme. Pairing engineers of different experience levels—cross-functionally where possible—accelerates knowledge transfer and surfaces operational knowledge that is rarely written down. Mentors should be matched on complementary skills, not just seniority.
• Let teams choose frameworks that suit them. Acceptance Test-Driven Development (ATDD) and Behaviour-Driven Development (BDD) are two approaches that help bridge skill gaps across the SDLC by grounding work in shared, human-readable specifications rather than implementation-specific details.

3. Identify and Remove Delivery Barriers

Before investing in new tools, audit what you already have. Systematically review your pipeline for bottlenecks—places where work queues, hand-offs stall, or feedback loops are too slow. Useful data sources include:

• Performance metrics: deployment frequency, lead time for changes, mean time to recovery (MTTR), and change failure rate.
• Customer feedback: bug reports, support ticket volume, and satisfaction scores tied to specific releases.
• Team self-assessment: ask engineers directly where they lose the most time on non-value-adding work.

Once barriers are visible, establish explicit best practices for how teams share work, communicate application health, and hand off changes for review or testing. Specifically, a well-maintained codebase with continuous testing at every stage can:

• Prevent memory leaks and regressions from reaching production.
• Stop poor coding patterns before they proliferate across the codebase.
• Ensure that every team member has timely, accurate visibility into build and deployment status.

4. Revisit and Modernise Your Automation Strategy

Automation is no longer optional in a high-velocity DevOps environment, but not all automation is created equal. A common mistake is treating automation as a one-time investment: scripts written years ago may be fragile, inconsistently maintained, or fundamentally unsuited to a pipeline that has since evolved.

A useful framework for your audit:

• Keep what works. Stable, deterministic automation that passes consistently should be left largely untouched. Unnecessary refactoring introduces new risk.
• Replace or augment what is flaky. Tests or scripts that produce inconsistent results erode trust and slow pipelines. Evaluate whether AI-assisted or model-based testing tools can improve coverage and reliability in those areas.
• Map automation to your CD goals. Every piece of automation should have a clear owner, a defined trigger, and a measurable contribution to shortening the path to production.

Advances in machine learning are making it possible to identify test gaps, predict failure-prone code paths, and prioritise test execution dynamically. These capabilities are genuinely useful when applied to areas where traditional rule-based automation struggles—but they are a complement to solid foundational automation, not a replacement for it.

Putting It Together

DevOps improvement does not require a wholesale overhaul. A periodic, structured review of roles, skills, process barriers, and automation maturity can compound into significant gains in delivery speed and quality. Start with one area, measure the impact, and use that momentum to tackle the next. Consistent incremental improvement is, after all, a core DevOps principle.

Overview

Continuous Delivery (CD) is the practice of keeping software in a releasable state throughout its entire development lifecycle. While the idea sounds simple, achieving it requires rethinking every aspect of a traditional software development process — from requirements engineering through to deployment.

This article describes how the teamplay development organisation at Siemens Healthineers began a transformation toward Continuous Delivery. It covers the strategy and tactics used to gradually and safely change a development process operating within a regulated medical domain.

About teamplay

teamplay is a cloud-based performance management solution for medical institutions developed by Siemens Healthineers. It connects healthcare professionals, imaging devices and institutions to help radiology and cardiology departments tackle large-scale data challenges and manage increasing cost pressure.

Once a healthcare institution is connected to the teamplay network, its imaging scanners continuously send data to the cloud. Two representative applications built on the platform are:

• teamplay Usage — monitors scores and trends such as patient changeover times and the number of examinations performed across different imaging scanners.
• teamplay Dose — provides insight into radiation dose levels and highlights deviations from internal and national thresholds.

Third-party developers can also integrate with teamplay via public APIs, and the number of such integrations was growing steadily at the time of writing.

The Technology Stack

teamplay services run on Microsoft Azure. The user interface is implemented as a Single Page Application in AngularJS. Frontend integration for third-party applications is handled via iFrames, which gives external developers the freedom to use their own technology choices while still plugging into the platform.

The Problem: Improving the Development Process

At the start of the transformation, teamplay releases were shipped on a quarterly cadence. The development team identified several goals for improvement:

• Release features more frequently and respond faster to user demand.
• Reduce batch sizes to lower the risk of each change.
• Eliminate — or significantly reduce — the stabilisation phase that preceded every release.
• Improve release-date predictability by increasing quality throughout the process.

The team’s first move was to automate development deployments and add automated sanity tests that checked core application functionality immediately after each deployment. This brought a meaningful improvement in product stability, but frequent releases and a shorter stabilisation phase remained difficult to achieve.

Adopting Continuous Delivery

Continuous Delivery is far more than deployment automation and automated testing. The goal is to maintain software in a releasable state throughout its development — a requirement that spans both technical engineering and requirements engineering. To help with this transformation, the teamplay team engaged Dave Farley (co-author of the book Continuous Delivery) as an advisor and coach.

Safety was a non-negotiable constraint. teamplay software is used within healthcare and is subject to medical device regulation, making high quality and compliance essential rather than aspirational.

The fundamental objectives of the transformation were:

• Increase the quality and frequency of feedback — so that teams and individuals can see the outcomes of their decisions quickly.
• Improve collaboration — across a geographically distributed organisation, enabling decisions to be made close to the work.
• Shift toward a disciplined engineering culture — using training, coaching and hands-on pairing to embed new practices.

The approach combined formal training in CD philosophy with hands-on coaching, pairing experienced practitioners alongside teams as they learned. Technical work focused on better automated tests, more efficient deployment pipelines, story mapping for requirements, and the use of Domain Specific Languages (DSLs) to create executable specifications.

Choosing a Pipeline Strategy

A critical early decision was how to reduce feedback cycle time. At the start of the transformation, the team waited between 24 and 48 hours to learn the outcome of a test run. The target was to reduce that to approximately one hour.

Three architectural options were considered:

• Optimise the existing monolithic pipeline — scale build servers, introduce incremental compilation, and run only tests affected by a given change.
• Decompose into microservices — create a dedicated pipeline per microservice, requiring backwards-compatible contracts between services.
• A middle-ground: one pipeline per teamplay application — making each application independently releasable without requiring a full microservice decomposition.

The team chose the middle-ground option. It avoided the complexity of optimising a monolithic pipeline and deferred the engineering investment required for a full microservice architecture. The microservice approach was noted as a possible future direction.

The Continuous Delivery Model

Through workshops, coaching sessions and training courses, the team established a visual model for Continuous Delivery that maps the complete journey from idea to production deployment.

The model identifies which role is responsible for each step and which methodology — TDD, BDD, DDD, or Pair Programming — applies at each stage. Roles include Product Owner (PO), Business Analyst (BA), Designer, Architect, Developer and Operations Engineer.

The pipeline itself has four stages: Accept 1 → Accept 2 → Staging → Production.

Process Walk-Through: From Idea to Commit

1. Hypothesis

Every new feature begins with a stated hypothesis in the form:

• We believe that this <capability>
• Will result in this <outcome>
• We will know we have succeeded when we see a <measurable signal>

The hypothesis scopes the work: only as much functionality and production instrumentation as needed to test the hypothesis should be built.

2. Low-Fidelity Prototype

The Product Owner and Designer create a low-fidelity prototype — a paper sketch or quick wireframe — to communicate the idea to other roles and gather early customer feedback before significant investment is made.

3. Story Mapping

The whole team — POs, Architects, BAs, Designers and Developers — collaborates to create a User Story Map. The map represents user journeys hierarchically, including steps performed outside the product where relevant. From the story map, the team identifies a Minimal Viable Product (MVP) slice and selects a single story for refinement.

4. BDD Scenarios

Stories are refined using BDD Scenarios written in Gherkin (Given / When / Then). Each role contributes scenarios from their perspective:

• PO — functional scenarios from a user perspective.
• Architect — scenarios covering load and security concerns.
• Operations Engineers — scenarios related to monitoring and logging.
• Business Analyst — ensures all “ilities” (reliability, scalability, maintainability, etc.) are covered.

Stories should be kept small. If a story produces more than roughly six scenarios it is likely too large and should be split. Crucially, scenarios must not contain implementation details or UI references — they should read as if written for first-level customer support.

BDD, DSL and Acceptance Testing

Once BDD scenarios are agreed, the team builds a Test DSL (Domain Specific Language) to express those scenarios in an executable and reusable form. The DSL is inspired by Domain-Driven Design, ensuring that the same language is used from initial discussion through to production code.

Dave Farley’s recommended four-layer acceptance test architecture provides the structural foundation:

• Layer 1 — Test Cases: Written in the abstract DSL, capturing user intent without implementation details.
• Layer 2 — DSL Implementation: Shared domain-level concepts reusable across many test cases (e.g. AddScannerToHospital, CalculateRadiationDoseByScan).
• Layer 3 — Protocol Adapters: Translate DSL concepts into real interactions with the system under test (REST calls, UI interactions, etc.).
• Layer 4 — System Under Test.

This separation means test cases are loosely coupled to the system. When implementation details change, only the Protocol Adapters need updating — the Test Cases and DSL remain stable. Tests are also functionally isolated, enabling parallel execution and shorter feedback cycles.

For a detailed description of this approach, see: Acceptance Testing for Continuous Delivery — Dave Farley (InfoQ).

Using Executable Specifications to Guide TDD

Once an Acceptance Test is written it is expected to fail immediately — there is no product code yet. The team follows a strict Red → Green → Refactor → Commit cycle:

• Red: Write the test. It fails because the production code does not exist.
• Green: Write just enough production code to make the test pass.
• Refactor: Clean up the code while keeping the test green.
• Commit: Push the change into the pipeline.

Within that cycle, developers also apply TDD at the unit test level — writing a failing unit test first, then the production code slice that satisfies it. This means each piece of functionality is tested at two distinct levels: the acceptance test level (what the system does) and the unit test level (how individual components behave).

Pair Programming

All programming tasks — DSL writing, acceptance tests, TDD, production code, pipeline work — are performed in pairs using the Driver-Navigator model:

• Driver: Types code and focuses on syntax and constructs.
• Navigator: Guides direction at a slightly higher conceptual level.

Roles switch regularly. Pairs are typically disbanded after completing a user story, with developers joining new pairs. This promotes shared code ownership, resilience against team attrition, faster onboarding of new members and faster recovery from test failures because many people understand each area of the codebase.

Pair programming can appear costly but it consistently delivers higher quality work and is a highly effective mechanism for embedding new techniques and culture within a team.

The Build and Deployment Pipeline

Once a commit enters the pipeline it passes through five stages:

• Build Agent (~5 minutes): Runs all unit tests and static code analysis. The 5-minute target is deliberate — it is roughly the time a developer pair can take a short break without switching context. Any failure at this stage rejects the commit.
• Accept 1 (~1 hour total for Accept 1 + Accept 2): Deploys the team’s component in isolation and runs all its Acceptance Tests. Any failure rejects the change.
• Accept 2: Deploys the component alongside its dependencies from other teams and runs Contract Integration Tests against integration points. If contracts between teams become sufficiently solid, this environment may be retired in future.
• Staging (Cut): A customer acceptance environment where selected customers can use the release candidate and provide real feedback. Production-grade monitoring and alerting are applied here.
• Production: Final deployment, also monitored with production-grade alerting.

A Team Information Radiator displays commit flow and environment state at a glance. Failures appear in red and immediately prompt developer action.

Why Short Feedback Cycles Matter

The relationship between feedback speed and software quality is direct. In a CD model, any failing test means the software is not in a releasable state. Long feedback cycles — say six hours — force developers to patch environments directly rather than re-committing a fix, because a full pipeline run would not complete until the following business day. This degrades discipline and erodes quality over time.

Targeting a one-hour feedback cycle from Accept 1 and Accept 2 enables developer pairs to make multiple commits per day. If a failure occurs, there are still multiple opportunities within the same working day to fix it, re-commit and see it pass cleanly.

Beyond the immediate benefit, driving toward short feedback cycles forces systemic improvements:

• Better team structures
• Improved automation
• Greater modularity
• Better automated testing
• Elimination of manual bottlenecks
• Improved requirements processes
• Better software design

Adoption Across Teams

Different teams adopted the CD model at different rates, which was expected. Key observations from the rollout:

• User Story Mapping was adopted by nearly all teams and proved particularly useful for making release prioritisation transparent and collaborative.
• TDD and Pairing were in regular use on some teams and being applied to selected features on others.
• BDD was being applied selectively, with teams growing confidence by experimenting on individual user stories before extending the practice more broadly.
• Team Pipelines were implemented by some teams, with ongoing work to optimise feedback cycle times.
• Kanban and #NoEstimates saw the fastest organic adoption — the majority of teams switched from Scrum and sprint estimates to Kanban and #NoEstimates voluntarily within weeks of being given the choice.

A key enablement mechanism was a CD Maturity Model that allowed teams to self-assess their adoption monthly and identify incremental improvements. Automatically generated dashboards surfaced CD metrics related to deployment stability, helping to guide the transformation in concrete terms.

Some teams dedicated a day per fortnight to learning — experimenting with new methodologies at small scale (a single user story) before scaling practices across all stories once confidence was established.

Conclusions

The teamplay CD transformation was explicitly framed as a long-term, incremental process — not a big-bang change. Even at an early stage, measurable results emerged. Applying TDD and Pair Programming to a new feature in a historically bug-prone area of the codebase enabled the team to deliver that feature with no production bugs.

The broader ambition is to become an experimental organisation — one that continuously runs small business and technical experiments in production to validate assumptions, rather than executing against plans built on assumptions alone. Continuous Delivery is the foundation that makes that kind of organisation technically and culturally possible.

Original article published on InfoQ. This summary was prepared for a DevOps engineering audience.

1. Encouraging the Right Conversations at the Right Time

One of BDD’s most underrated strengths is the culture of questioning it creates. Teams practising BDD naturally ask: Why is this feature important? Why does it need to ship now? How much of it is actually enough? These questions — often awkward to raise in traditional delivery models — become standard practice in BDD-driven ceremonies such as Example Mapping and Three Amigos sessions. The result is a more constructive dialogue between business and engineering before a single line of code is written.

2. Better Commitment and Business Buy-In

BDD places heavy emphasis on business value. By requiring concrete, executable examples to justify priority, it pushes stakeholders to articulate why a feature matters rather than simply asserting that it does. Engineers, in turn, better understand the reasoning behind prioritisation decisions and are therefore more likely to commit to them. Teams practising BDD tend to spend less time negotiating over pet features and more time delivering outcomes that matter.

3. A Shared, Ubiquitous Domain Language

BDD encourages business and development teams to build a shared vocabulary through collaborative tools such as product discovery workshops, story maps, user stories, acceptance criteria, and Gherkin-style scenarios (Given / When / Then). This ubiquitous domain language is not merely jargon for domain experts — it is understandable by every member of the team, including QA engineers, UX designers, and new joiners. A common language reduces misinterpretation, lowers the barrier to entry for new team members, and decreases the cognitive complexity of the domain model itself.

4. Focus on Behaviour, Not Implementation

Teams new to Test-Driven Development (TDD) often fall into the trap of focusing too heavily on testing their implementation rather than specifying the system’s observable behaviour. BDD corrects this by anchoring conversations around what the system should do for the user, not how it is internally built. This outside-in approach delays implementation decisions until they are necessary, avoiding premature architecture and over-engineering. BDD also helps strike the balance that up-front analysis, design, and test planning struggle to achieve: just enough detail, just in time.

5. Supporting Evolutionary Design

Agile — and eXtreme Programming in particular — has established that fully specifying requirements upfront is neither practical nor desirable. BDD embraces this reality. Because BDD scenarios are written collaboratively and incrementally, the system’s design is free to evolve alongside a deepening understanding of the product. Rather than locking in decisions early, teams can adapt their architecture and behaviour specifications as business needs change, reducing the cost of late-stage rework.

6. Breaking Down Knowledge Silos in Distributed Teams

Distributed teams frequently suffer from domain knowledge gaps — particularly sub-teams that are organisationally or geographically distant from the business. These gaps lead to misunderstood requirements, rework, and frustration on both sides. BDD does not eliminate this problem entirely, but it actively encourages closer collaboration and creates artefacts — living documentation in the form of executable specifications — that keep domain knowledge visible and accessible. It also promotes a generalising-specialist mindset, supporting XP practices such as pair programming and collective code ownership.

7. Greater Return on Investment (ROI)

Behaviour has a longer shelf life than implementation details. Code changes frequently; the business rule it encodes changes far less often. BDD captures business rules in human-readable scenarios that remain valid and meaningful even as the underlying implementation evolves. When business rules do change, updating a BDD scenario is explicit and traceable — far preferable to hunting through code comments or stale Word documents. This makes BDD a durable investment in documentation and test coverage simultaneously.

8. Predictability and Team Confidence

Teams that practise BDD consistently report greater predictability in their delivery and higher confidence in the correctness of their software. Because acceptance criteria are agreed upon before development begins and automated as executable specifications, the definition of “done” is unambiguous. Regression suites built from BDD scenarios give engineers a safety net that supports refactoring and continuous delivery pipelines.

Clarifying the Team Definitions

In the context of BDD, it is helpful to distinguish between two collaborative groups:

• Business Team — the people focused on “Are we building the right product?” This typically includes Product Owners, Product Managers, Stakeholders, UX Designers, Subject Matter Experts, and Business Analysts.
• Development Team — the people focused on “Are we building the product right?” This typically includes Architects, Tech Leads, Developers, Testers, Graphic Designers, and Database Administrators.

BDD’s core value proposition is that it forces these two groups to collaborate continuously, rather than handing requirements over a wall and hoping for the best.

Is BDD Right for Your Team?

BDD delivers the most value when both business stakeholders and engineering teams are willing to invest time in collaborative specification. It is not a silver bullet — teams working in isolation, or organisations where business stakeholders are unavailable for regular collaboration, will struggle to realise its benefits. However, for teams looking to reduce rework, build shared understanding, and produce living documentation that stays relevant over time, BDD is a compelling practice worth piloting.

What Is Behavior-Driven Development (BDD)?

Behavior-Driven Development (BDD) is an evolution of two earlier practices: Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD). It retains the discipline of writing tests early while adding a critical ingredient that TDD often lacks — cross-functional collaboration.

In a traditional TDD workflow, testing and development can happen in relative isolation. Developers write failing unit tests, implement the code to pass them, and refactor — often without continuous input from business stakeholders. BDD breaks down that silo by bringing product owners, business analysts, testers, and developers together to define, in plain language, what the software should do before a single line of production code is written.

The result is a shared understanding of requirements that reduces ambiguity and misalignment between what the business wants and what engineering delivers.

BDD and Agile: Complementary but Not Exclusive

BDD is frequently associated with Agile, but it is not strictly an Agile practice. It is fundamentally a requirements-design and test-design technique that can be applied in any development methodology.

That said, BDD and Agile are a natural pairing for two reasons:

• Fast feedback loops: Agile sprints demand rapid iteration. BDD scenarios, written before development begins, give developers and testers immediate, concrete targets to work toward within each sprint.
• No dedicated testing phase: Agile deliberately avoids a long, separate QA phase at the end of a release cycle. BDD enables automation testing to be introduced early in the development process, protecting teams from expensive regressions as the codebase grows.

For non-Agile teams, BDD still offers value as a structured way to document requirements and design acceptance criteria — it simply won’t benefit from the tighter sprint cadence that amplifies its feedback advantages.

A Core Benefit: Bridging the Gap Between Business and IT

One of BDD’s most tangible advantages is the way it structures requirements. Rather than relying on abstract, imperative specification documents, BDD uses Gherkin — a plain-language, structured syntax — to express requirements as concrete, real-world scenarios.

A Gherkin scenario follows a familiar three-part pattern:

Feature: User login

  Scenario: Successful login with valid credentials
    Given the user is on the login page
    When they enter a valid username and password
    Then they should be redirected to the dashboard

This format is readable by non-technical stakeholders, executable by automated test tools, and precise enough to drive development. It replaces vague requirements with verifiable, living documentation that stays in sync with the code.

The net effect is a much shorter communication loop between business and IT — misunderstandings surface during scenario-writing workshops, not during user acceptance testing weeks later.

The Cucumber Framework: What It Does and What It Doesn’t

What Cucumber Is

Cucumber is one of the most widely used open-source tools for implementing a BDD workflow. It reads Gherkin feature files and maps each step (Given, When, Then) to executable test code written in a supporting language such as Java, Ruby, JavaScript, or Python. Its primary purpose is to act as a concept layer — a bridge between human-readable specifications and automated test execution.

A Cucumber feature file is not merely a test script. It is a document that captures:

• A brief explanation of the feature and its business value
• The business rules that govern the feature’s behavior
• Concrete scenarios that illustrate each rule with real data

This makes feature files useful artifacts for the entire team, not just QA engineers.

What Cucumber Is Not

A common and costly misconception is that adopting Cucumber — or any BDD tool — will automatically transform an organisation’s approach to quality. It will not. Cucumber is a framework, not a strategy.

Specifically, BDD tooling will not resolve:

• A shortage of automation expertise: If your team lacks engineers who know how to build and maintain reliable automated tests, adding Cucumber simply means those problems are now expressed in Gherkin.
• Inadequate test coverage: Gherkin scenarios are only as good as the thinking that goes into them. Shallow scenario design produces shallow coverage, whether automated or manual.
• Low application testability: Applications that lack stable APIs for service-level testing, use poorly named UI elements, or are built on legacy technologies (such as Flash-based interfaces) will remain difficult to automate regardless of the BDD tooling applied.

BDD tooling supports good practices — it does not create them. Teams must invest in automation skills, thoughtful scenario design, and testable application architecture alongside any tooling decision.

Summary: Five Key Takeaways

1. BDD is a collaborative practice, not just a testing technique. Its value comes from bringing developers, testers, and business stakeholders together to define behavior before code is written.
2. BDD works in any methodology but delivers the greatest feedback advantage in Agile environments where there is no separate testing phase.
3. Gherkin scenarios add structure and objectivity to requirements by anchoring them to real-world data and examples rather than abstract specifications.
4. Cucumber provides a concept layer that maps readable Gherkin scenarios to executable test code — its purpose is better upfront test definition and reduced redundancy, not magic automation.
5. BDD tools do not fix fundamental gaps in automation skills, test coverage strategy, or application testability. Address those first.