Filed under: BDD, — Tags: Automated acceptance tests, BDD, Behaviour-Driven Development, Concrete examples, Conversations, Cucumber — Thomas Sundberg — 2019-04-24
Defining what Behaviour-Driven Development, BDD, is not easy. It is sometimes described as a bounded context of ideas.
What is rather clear to me is that there are a two properties everyone seems to be able to agree upon.
These are:
In order to get full benefit from these, I want to add
to the list.
This will give us the benefit of
Talking to each other is a great way to communicate. If something is hard to understand, you can always ask and get a better explanation. The alternative is to communicate using written text. It doesn't work nearly as good. If you don't understand what I mean in this text, you can't ask me directly.
For most people, it is easier to understand a concrete example rather than an abstract explanation. This is how you learn new things. You look at an example, follow it and after some time you build an active knowledge. I sometimes find it hard to say when I stopped following an example and moved from passive to active knowledge. It happens gradually.
A concrete example may look like this:
When we add the numbers 1 and 2, we can take one pen to represent the 1 and two pens to represent the 2 and put them together. Then count the numbers of pens... 1, 2, 3... 3 pens is the sum of 1 pen added to 2 pens.
The same example, but more abstract, may look like this:
When we add, we're taking the value of one set and increasing it by the value of another set to get the sum.
The concrete example isn't generalized, it is only valid in a specific context. It is easier to explain, and for most people, easier to understand. The generalized example is valid in all contexts, but harder for most people to understand without concrete examples.
The abstract example is what we will implement, the concrete example is what we will use to verify that the implementation is correct.
A concrete example can be questioned. Did you really mean that this should happen in that situation? This is much better, and safer, than questioning the person who described the example. This is an example of non violent communication.
A concrete example is only valid in a specific context. Changing the context may or may not result in a new outcome. If changing the context changes the outcome, you have a new thing to consider when implementing the program.
If the result of changing the context is unclear, nobody really knows what should happen, you have found an area where you lack knowledge. This is a great way to find a dangerous thing sometimes referred to as The unknwon unknown.
Sharing concrete examples allow everyone to build a shared and common knowledge.
To really benefit from the conversations and the concrete examples, you want to use them for automating your acceptance tests. That is, automate the tests that will help you show that the system behaves as expected given a certain context.
Automating examples are easier if you allow them to drive your development. This is where the first D in BDD comes from, driven. Adding the automation after the program is written is possible but usually not a good idea. If possible, I advice against it. The result is much better if you add the tests before and let them lead your way to a complete program.
The ultimate tool for most software development is to write code that encodes the desired behaviour. The problem is to know which code to write. Your automated acceptance tests will guide you in the process. When they pass, your system does what the examples specify. The program may do more things, but it wont do less.
Behaviour-Driven Development, BDD, is a set of ideas that promotes this development style:
Make sure that the cycle time is short, rather hours than days if possible.
Hands on experience is invaluable, attend the BDD Kickstart 22nd - 23rd of May in Stockholm and learn all the skills needed.
I would like to thank Malin Ekholm for feedback.
RSS