I finally finished the second edition of BDD in Action from John Ferguson Smart and Jan Molak, and I can highly recommend it as a reading to anyone practising agile software development.
Let’s be clear from the start that practising behavior-driven development or test-driven development is not easy. And this book does not guarantee that you will be able to change your team’s methods and ways of working. But then again, it can be a motivator and inspiration on your path forward.
In principle, it is easy to agree that BDD is a good idea. Still, in practice, it is much more challenging to develop common methods and language and adopt technologies supporting collaboration and knowledge creation throughout the team.
If figuring out requirements and writing them out concisely would be easy, there would not be a need for these books - nor a need for discussions about what practices help people discover and understand the needs of the user and requirements of the system better.
Developing a common language and concepts that are also business domain concepts helps collaboration and understanding. But it requires that the team and stakeholders are ready to play the game together, and figure out and define abstractions that are relevant to the problem-solving.
This thinking and collaboration challenge is the big thing to tackle before complicating things with technology and technology-focused terms.
Developers practising BDD typically use an outside-in approach. When they implement a feature, they start from the acceptance criteria and work down, building whatever is needed to make those acceptance criteria pass. The acceptance criteria define the expected outcomes, and the developer’s job is to write the code that produces those outcomes. This is a very efficient, focused way of working. Just as no feature is implemented unless it contributes to an identified business goal, no code is written unless it contributes to making an acceptance test pass and, therefore to implement a feature.
I haven’t been able to introduce or implement, nor seen BDD practised anywhere ‘properly’. Properly meaning here that there would be a good shared executable specification as living documentation. And that it would not be owned just by a QA person. And that the design of a feature or increment would actually start by collaborating around the specification to a sufficient level.
I use vague terms like properly and sufficient to get free out from jail cards, as the goal in teams has never been to do BDD - but rather do good products that enable good things to happen for users.
And even though people have not been following ideas and guidelines stated in practices, good work and results has emerged. It is just that even I have seen the challenges in collaboration and follow-up. Some balls have been dropped, some adhoc decisions have been made and not documented - and people have continued their lives with dicerged ideas and specifications about the product.
The big promise and idea for me in BDD have always been the improved collaboration and common language between different parties collaborating in designing and maintaining a product through the different lifecycles.
I love to write narrative descriptions and figure things out instead of just jumping into coding. However, while coding, I also learn something new about the problem, domain and capabilities available to solve the problem. Hence the coding usually has a feedback loop to the narrative description. In a perfect world, these would be kept in synch and used as a common communication and collaboration tool.
And here, the history is filled with different tools that have not been what I wished in terms of being easy to take into use and adopt. Teams have had existing behaviours and expectations that have not necessarily worked well with the tools’ constraints.
Design and narrative documentation start at Figma and/or in some rapid prototyping tool. On the other hand, specifications and tests get coded into preferred testing frameworks and potentially in multiple repositories and tools - as frontend developers and api developers have quite different active needs. Hence there is no shared understanding, specification and runnable follow-up with the specification to check that the product adheres to things discussed during discovery and design.
While reading BDD in Action 2nd edition, I got interested in the promise of Serenity BDD as a tool to bridge this gap by providing a good and familiar testing experience with Cucumber or JUnit and including the necessary additional narrative. But it wasn’t immediately smooth sailing.
As I started to test the framework, I learned that there are some rough edges, as only some features are available when using JUnit. But then again, it looks like a nice experience if you are using Cucumber for defining BDD scenarios. And it seems like modern IDEs are making the experience of editing Cucumber features and then creating related step functions much more straightforward.
Serenity BDD was not the immediate answer to my wishes, but I am impressed enough to invest more time to play around with it. I see value in having the living documentation with the tests, and I want to learn more about the ideas in Serenity BDD. This even though I don’t see myself having any opportunities to using Serenity BDD in any projects for some time.
If you have succesfully adopted BDD practices or have any experiences around the topic, I am looking forward hearing your experiences.