Sponsored:

Build the Future of Apps on HubSpot:New developer products introduce deeper extensibility, flexible UI options, modern development tools, and more—shaping a more powerful, customisable platform experience.Learn more.

Hi ,

Welcome to a brand new issue of ProgrammingPro.

In today’sExpert Insight, we bring you an excerpt from the recently published book, Domain-Driven Design with Golang, which explains how Behaviour-Driven Development (BDD) extends Test-Driven Development (TDD) by using natural language tests to improve collaboration between engineers and domain experts, illustrated with Go examples using the gobdd framework.

News Highlights: AI tooling advances as Docker, Solo.io, and AWS launch new agent frameworks and benchmarks; GCC 15.1 delivers major Rust, C, C++, and Cobol upgrades; GitHub previews its AI-powered MCP Server; and InfoQ’s 2025 report highlights agentic AI, small LMs, and privacy engineering trends.

My top 5 picks from today’s learning resources:

But there’s more, so dive right in.

Stay Awesome!

Divya Anne Selvaraj

Editor-in-Chief

Featuring:

Sergio Castell-Security Researcher
Dario Dallefrate-Product Marketing Manager

Date/time:

Tuesday May 13, 20254 PM CET (10 AM EDT)

Sign Up |Advertise

Here’s an excerpt from “Chapter 8: TDD, BDD, and DDD" in the book, Domain-Driven Design with Golang, by Matthew Boyle, published in December 2022.

BDD is an extension of TDD that aims to enable deeper collaboration between engineers, domain experts, and quality assurance engineers (if your company employs them). A diagram of how this
works with TDD is shown (in Figure 8.6).

The goal of BDD is to provide a higher level of abstraction from code through a

domain-specific language (often referred to as a DSL) that can become executable tests. Two popular frameworks for writing BDD tests is the use of Gherkin (https://cucumber.io/docs/gherkin/reference/) and Cucumber (https://cucumber.io). Gherkin defines a set of keywords and a language specification. Cucumber reads this text and validates that the software works as expected. For example, the following is a valid Cucumber test:

Feature: checkout Integration
Scenario: Successfully Capture a payment
Given I am a customer
When I purchase a cookie for 50 cents.
Then my card should be charged 50 cents and an e-mail receipt
is sent.

Some teams work with their domain experts to ensure their acceptance criteria in their ticketing system are in this format. If it is, this criterion can simply become the test. This aligns nicely with DDD.

Now that we have a high-level understanding of BDD, let’s take a look at implementing a test in Go. We are going to use the go-bdd framework, which you can find at https://github.com/go-bdd/gobdd.

Firstly, let’s install go-bdd in our project:

go get github.com/go-bdd/gobdd

Now, create a features folder:

Inside the features folder, let’s add a file called add.feature with this inside it:

Feature: Adding numbers
Scenario: add two numbers together
When I add 3 and 6
Then the result should equal 9

Next, let’s add an add_test.go file and the following:

package chapter8
import (
"testing"
"github.com/go-bdd/gobdd"
)
func add(t gobdd.StepTest, ctx gobdd.Context, first, second
int) {
res := first + second
ctx.Set("result", res)
}
func check(t gobdd.StepTest, ctx gobdd.Context, sum int) {
received, err := ctx.Ge

if err != nil {
t.Fatal(err)
return
}
if sum != received {
t.Fatalf("expected %d but got %d", sum, received)
}
}
func TestScenarios(t *testing.T) {
suite := gobdd.NewSuite(t)
suite.AddStep(`I add (\d+) and (\d+)`, add)
suite.AddStep(`the result should equal (\d+)`, check)
suite.Run()
}

In the preceding code, we add a bdd step function called add. This function name is important; the framework knows that when I add 3 and 6 gets mapped to this function. If you change the name of this function to “sum”, you’d need to update the feature file to say, when I sum 3 and 6 together. We then perform our logic and store it in the context so that we can recall it later.

We then define a check function that is our actual test; it validates our assertions. Finally, we set up a test suite to run our code.

If you run the preceding test, it should pass.

This might be your first time seeing a BDD-style test, but I bet it’s not your first time seeing a unit test. Why is that?

As you can see, although BDD tests are closer to natural language, it pushes a lot of the complexity down into the tests. The preceding example we used is trivial, but if you want to express complex scenarios (such as the cookie example we used previously) there is a lot of scaffolding the developer needs to implement to make the tests work correctly. This can be worthwhile if you have lots of access to your domain experts and you are truly going to work side by side. However, if they are absent or not invested in the process, unit tests are much faster and more engaging for engineering teams to work with. Much like DDD, BDD is a multidisciplinary team investment, and it is worth ensuring you have buy-in from all stakeholders before investing too much time in it.

Domain-Driven Design with Golang was published in December 2022. Packt library subscribers can continue reading the entire book for free or you can buy the book here!

That’s all for today.

We have an entire range of newsletters with focused content for tech pros. Subscribe to the ones you find the most usefulhere.

If your company is interested in reaching an audience of developers, software engineers, and tech decision makers, you may want toadvertise with us.

If you have any suggestions or feedback, or would like us to find you a learning resource on a particular subject, just respond to this email!