TDD, BDD, and DDD are highly complementary approaches in product development, enhancing both understanding of requirements and product quality.
What Are TDD, BDD, and DDD Approaches?
BDD (Behavior Driven Development)
Behavior-Driven Development (BDD), an Agile practice created by Dan North in 2003, aims to create functional tests using a natural language understood by all.
However, BDD goes even further by ensuring that the development team is clear about user needs. The “Given… When… Then” structure, often used to define a user story, can sometimes lead to ambiguity. These acceptance criteria (some call them acceptance tests) eliminate any doubts about understanding when well-written.
These acceptance criteria are written in a natural language called Gherkin. Here’s a simple example:
Given that I am the customer on the product page
When I click "Add to Cart" on the product with ID "255"
And the stock is "3"
Then the product is added to the cart.
Each user story will propose several acceptance criteria like these to define all possible behaviors, including positive and negative cases. To minimize the future obsolescence of these tests, the implementation should not be included.
By writing these tests in advance with business experts and users involved in the requirement, the team has a much better chance of ensuring that they meet real user needs while respecting any constraints, be it legal or business-related. I would describe this approach as the optimized entry point for future feature development.
If you want to know more: BDD (Behavior Driven Development)
DDD (Domain Driven Design)
Domain-Driven Design (DDD), introduced by Eric Evans in 2003, aims to make the business domain a cornerstone of software design. DDD won’t tell you how to “code” your application but will guide you to design it to reflect business rules.
This approach continues the general trend of bringing all product design stakeholders together and breaking down silos between different expertise areas.
Here are some significant advantages this approach brings:
- Removing any possible ambiguity between business and development teams
- Software design that favors future adaptability
- Reduced potential for regressions
It’s essential to understand that all types of experts (business, developers, etc.) must work together in this approach.
I will write some articles soon about this approach, which is very popular in the software craftsmanship community but is still not widely adopted within companies (although it’s increasingly common). Understanding DDD in just a few lines is indeed challenging.
Although this approach is very different from BDD, it complements it entirely.
- We gather requirements with business experts (refining expectations) with BDD.
- We design an application that reflects the complexity of the business domain with the help of business experts using the DDD approach.
TDD (Test Driven Development)
Test Driven Development (TDD) is a software development approach that involves writing unit tests for a function before writing the content of that function. It’s a well-known practice in the world of continuous integration.
The purpose of this practice, known in XP, Scrum XP, or DevOps, is to specify what the code will be exposed to even before it’s written. This practice radically changes developers’ traditional concepts.
While TDD enhances product quality and reduces future regressions, the notion of a “test” is not its primary function. TDD mainly helps developers find a solution to a test’s demand.
By creating the test beforehand, developers will be guided toward the expected solution. No more time wasted on features with a high risk of delivering an unsatisfactory result.
Although this approach is more focused on “development,” it also complements the two previous approaches we’ve discussed.
- We gather requirements with business experts (refining expectations) with BDD.
- We design an application that reflects the complexity of the business domain with the help of business experts using the DDD approach.
- We strengthen our application with tests that reduce future regressions while being guided by the expectations of each function individually with TDD.
Conclusion: TDD, BDD, DDD
These three approaches, which operate at different levels of software design, are highly complementary. Although mastering them requires an initial investment, they will help teams create high-quality software.
This TDD, BDD, DDD trio will allow you to:
- Design software that can evolve over time.
- Deliver software that truly meets needs.
- Reduce potential technical debt.
- Minimize slowdowns in future developments, often caused by increasingly complex systems.
Quality is priceless and, in the long term, highly profitable for businesses.
Be the first to comment