"BDD In Action: Behavior-Driven Development for the Whole Software Lifecycle" by John Ferguson Smart is a book that aims to cover the full spectrum of BDD practices from requirements through to the development of production code backed by executable specifications and automated tests. As a result the book is broken into four sections: BDD introduction, requirements analysis techniques, BDD technical techniques and broader uses of BDD.
BDD is a term (and practice) that is often misunderstood, so the book takes the time to define BDD (and how it differs to TDD, ATDD and Specification by Example) as well as outlining the advantages, disadvantages and core principles.
Behavior-Driven Development (BDD) is a set of software engineering practices designed to help teams build and deliver more valuable, higher quality software faster. It... provides a common language based on simple, structured sentences... that facilitate communication between project team members and business stakeholders.
BDD begins with the focus on features that deliver business value (or what it refers to as capabilities), so understandably the next section of the book covers requirements definition using BDD and the important question of ensuring you are building the right thing. There is a comprehensive overview of techniques such as Feature Injection, Impact Mapping, the Purpose-Based Alignment Model, Real Options and Deliberate Discovery.
Users need our software to give them the capabilities that will help them contribute to these business goals. Features are what we deliver to users to support these capabilities. A feature is a tangible piece of functionality that will be valuable for users...that may or may not be deliverable in a single iteration... Features are expressed in business terms and in a language that management can understand.
The book then continues to explain the decomposition of features into manageable chunks (user stories) for planning purposes and the use of concrete examples to ensure understanding and clarify any uncertainity.
BDD practitioners express concrete examples as executable scenarios, using a semi-structured “given ... when ... then” format that’s easy for both stakeholders and team members to read.
A large section of the requirements definition section is dedicated to tips and examples of how to write executable scenarios, using both Gherkin and JBehave language formats and how to organise them using feature files and tags before then explaining how these can be automated.
Scenarios describe the high-level requirement... Step definitions interpret the scenario texts and call the test automation layer to perform the actual tasks... The test automation layer interacts with the application under test... Using a layered architecture like this is a key part of writing maintainable, readable, auomated acceptance tests.
Section three of the book switches from requirements to a more technical focus on coding and automated testing and provides a number of techniques for code design, unit testing, automated test design, UI testing and testing non-functional requirements. Again, this section contains many examples in different languages including C#, Java, JavaScript and Python and tools such as Selenium WebDriver, SpecFlow and Thucydides.
When you write automated acceptance criteria, using layers can help you isolate the more volatile, low-level implementation details of your tests from the higher level, more stable business rules... The Business Rules layer describes the requirement under test in high-level business terms... The Business Flow layer... represents the user’s journey through the system to achieve a particular business goal... The Technical layer represents how the user interacts with the system at a detailed level—how they navigate to the registration page, what they enter when they get there, how you identify these fields on the HTML page, and so forth.
The final section of the book covers some of the outputs from BDD process including living documentation and the continuous delivery process.
The reports generated by the automated tests... which combine the original specifications, acceptance criteria, and test results, are what we call living documentation... First and foremost, BDD reports document and describe what the application is expected to do, and they report whether or not the application actually performs these operations correctly. When you drill down into the details, a BDD report also illustrates how a particular feature or functionality is performed, from the user’s perspective.
Overall, this is a very balanced book that takes the reader on the journey from the initial conversation through the requirements, development and testing phases of feature development. Unlike many of the other books on this topic, it covers the entire lifecycle whilst also covering in-depth technical and testing aspects without getting lost in the coverage of a specific tool or language.
This book should be of interest to each of the "three amigo" roles in BDD - developers, testers and business analysts / product owners - with the entire book being very readable and offering insights for a well balanced cross functional Agile team. This however is potentially the books disadvantage - the end to end nature may unfortunately scare non-technical readers whilst the technical readers may perceive a lack of in-depth coverage for a particular tool or language. Regardless, this is a book that covers the topic of BDD (and many associated techniques) extremely well and is a good place to start for anybody looking for an understanding of BDD or approaches to implementing it effectively.
Recently, InfoQ caught up with the author John Ferguson Smart about the book.
InfoQ: Congratulations on the book. There are a number of BDD and related books on the market, what drove you to write this book and what do you see is its point of difference?
John: I felt the BDD space was missing a book that covered the whole picture, of BDD from the requirements discovery right through to coding the application, writing automated acceptace tests, and delivering living documentation. People often have a very limited perception of BDD, so I wanted to make people more aware of how broad and inclusive BDD actually is. Gojko Adzik's "Specification by Example" is a great set of case studies, but many new practices and tools have emerged and evolved since that book came out. There are also many books on TDD, but I felt they didn't capture the flow between requirements discovery and identifying business value, and remained a bit too focused on the technical aspects, and used fairly dated technology stacks. And there were very few that were immediately useful for a Java developer.
InfoQ: People are often confused about the definition of BDD, what is your basic explanation?
John: I like to start off by describing BDD as a way of collaborating and using conversations about concrete examples to build up a shared understanding of what features will deliver value to the organization. When these conversations are done well, you can use the examples to define clear and unambiguous acceptance criteria for these features. If you automate these acceptance criteria, you get fast and reliable feedback about what features have actually been built, using language that the business can understand.
And you can use this principle at any level. At a more technical level, the clear acceptance criteria help us know what to build, what not to build, and to understand why. BDD promotes writing executable technical specifications for the code you write, before you write the code. So we get both well tested code and reliable specifications for this code that act as technical documentation moving forward. So in this sense, BDD unit testing tools like Spock, RSpec and Jasmine make it easier and more intuitive to practice Test Driven Development more effectively.
But BDD is not a strictly defined set of practices. There is no "Certified BDD Practitioner" certificate, or official body that will declare what is canon BDD and what isn't. For example I work with many teams on the other side of the world to help them express their requirements more clearly, so the collaboration is not necessarily face-to-face (though it is ). And I know teams that use conversations and write BDD-style scenarios to clarify their understanding of the requirements for non-IT projects, so there is no automation involved.
InfoQ: You talk in the book about the importance of collaboration in BDD, especially between the "three amigos" (developers, testers and the customer / analyst). What are some of the key differences that each of these roles need to be successful in adopting BDD?
John: I like to say "The three amigos, where 'three' is a number between three and seven". The roles are very complementary, and there needs to be a sort of creative tension to get the best results. The role of the BA (or product owner, or customer) is essentially to present the customer's requirements, or the perceived customer requirements, using conversation about concrete examples of how the customer will use and benefit from the application. The role of the other participants is to challenge these examples, to ask for counter-examples, to ensure that no assumptions are left unsaid. Testers tend to be good at finding counter-examples or edge cases that the BA, or even the business, may not have considered. And developers tend to be good at making sure that the features are technically feasible, and possibly suggesting alternative ways of achieving the same goal that might be technically superior.
InfoQ: Apart from writing the book, you also teach a number of classes and run a number of dojos around BDD and test automation. Are there any recurring aha moments that you see from participants?
John: The biggest "Aha" moment is when people realise how big a role collaboration plays. People often see BDD as a test automation practice, or as a different way to write requirements and acceptance criteri with lots of "Given..When..Then"s. But the real value of BDD comes from the shared understanding that comes out of the discussions that produce these acceptance criteria.
InfoQ: People often (wrongly) associate BDD primarily with the agile approach to working. What is the key benefit that BDD brings to the software development process in general?
John: Many BDD practices can be useful for both agile and more prescriptive development processes. For example, writing acceptance criteria in a way that can be turned into executable form (or "executable specifications") can help ensure that the acceptance criteria are unambiguous and of high quality, though the feedback and review cycles may be slower if there is less face-to-face collaboration between the BAs and the other team members during the definition of these requirements.
That said, an agile process gives the team more scope to manage uncertainty and to adapt to their evolving understanding of the requirements and the solution they are building, and practices like the 3 amigos and collaboratively defined acceptance criteria are great ways to flush out uncertainty in the requirements.
No matter what development process you are using, writing code using BDD practices (in particular, the idea of writing "executable specifications" for your low-level APIs) is a great way to produce reliable, well-tested and well-documented code that is both built well and fit for purpose.
I've also seen some BDD practices and tools, in particular the idea of "living documentation", used very effectively as a way to retro-fit unit and acceptance tests to a legacy code base. BDD Test Automation, both at the unit and acceptance testing levels, turns out to be a great way to understand and document what an application does, and to produce cost-efficient and well-targetted regression tests.
InfoQ: Tooling is a big part of the book - both what tools to consider and also some hints for usage. What are some of the gaps you still see in the tools available today?
John: I find there could be much smoother integration between agile project management and requirements definition, acceptance test automation and reporting.
InfoQ: You are the main contributor to Serenity BDD (previously known as Thucydides). What prompted you to write it and how does it help in the BDD space?
John: Serenity is an embodiment of my ideas about how requirements and automated tests should fuse together and produce useful, accessible living documentation instead of just simple test reports.
It builds on top of BDD tools like Cucumber and JBehave, or even JUnit, to help you write cleaner and more maintainable automated acceptance and regression tests. Serenity tries to facilitate many good habits in test automation, such as layers of abstration and self-documenting automation code.
Serenity also makes it easy to relate the acceptance tests back to the requirements they are demonstrating. The idea is to produce reports that tell you not only what tests have been executed, but more importantly, what requirements have been tested.
InfoQ: The book writing process is often quite lengthy. Now the book is out, are there any topics you wished you could have added to the book?
John: I would have liked to have added some more material on story mapping, which is an extremely powerful requirements discovery technique that plays very nicely with other BDD practices.
And I would have also liked to add a chapter on defining and testing microservices and web service APIs using BDD techniques. Although I do talk about this in the book, there are some interesting tools emerging now in the "consumer driven contract" space, such as Pact and Pacto, which are effectively a form of "executable specifications".
InfoQ: What does the future hold for BDD as a practice?
John: I think BDD has a big role to play in the microservice space. For example, consumer driven contract testing is a great start to microservice testing, but it remains relatively low level and test-focused. There is a lot of scope to integrate concepts from BDD, such as driving out and discovering the requirements for these web service contracts, and then reporting back on the consumer-driven-contract style automated tests to illustrate what web services are available, how they work, and how they relate to higher-level business requirements.
And there is still a lot more work to be done to streamline the concepts of executable specifications, living documentation, and what I call "feature coverage" - reporting not only on what tests were executed, but on what features and capabilities have been delivered.
The central idea of BDD, that collaboration and conversation around concrete examples is an effective way to understand a problem domain, won't go away any time soon. And on a technical level, the tools will certainly evolve, but I certainly see the idea of writing executable specifications at all levels growing to become a standard technical practice.
Discount code ‘smartinfoq’ for 40% off 'BDD in Action' -- all formats at manning.com.
About The Book Author
John Ferguson Smart is a well-regarded consultant, coach and trainer in technical agile practices based in Sydney, Australia. A prominent international figure in the domain of requirements discovery, behaviour driven development, automated testing, developer best practices and continuous integration and delivery, John helps organisations around the world to improve both their collaborative and their technical practices and to optimise their development processes and infrastructures. A renowned speaker at many international conferences and events, John is the author of the popular “Java Power Tools” and “Jenkins: The Definitive Guide”, both published by O’Reilly, as well as “BDD in Action”, published by Manning.