My experience of the CukeUp 2016 BDD conference

Perhaps the simplest short description that I have come across to describe Behaviour-Driven Development is by Margaret Rouse:

'Behaviour-driven development (BDD) is a software development methodology in which an application is specified and designed by describing how its behaviour should appear to an outside observer. A typical business application project would begin by having stakeholders offer concrete examples of the behaviour they expect to see from the system. All coding efforts are geared toward delivering these desired behaviors. The real-life examples gleaned from stakeholders are converted into acceptance criteria with validation tests that are often automated. The results of these tests provide confidence to stakeholders that their desired business objectives for the software are being achieved.' (http://searchsoftwarequality.techtarget.com/definition/Behavior-driven-development-BDD)

Over the past year and a half, I have been reading about and using BDD tools, and have recently introduced some BDD tools and practices into Digital Transformation projects in Kainos. The experience of using BDD tools like SpecFlow to facilitate outside-in development and TDD has brought great benefits to the quality of the development process as well as new learnings for myself and my colleagues who have been involved in these projects. But reading and experimenting can only take us so far personally, I needed to understand more about what other BDD practitioners are doing so that I could see where I can improve and can better contribute towards BDD practices in Kainos as this fantastic software development methodology grows in popularity and becomes more of a common standard in software development communities. So thanks to Kainos, I was lucky enough to have the opportunity to attend 'CukeUp! 2016 - the progressive BDD conference for testers, developers and product owners'. As well as being the first tech conference I've ever had the good fortune of attending, I also landed up (unexpectedly!) speaking at the conference. The event consisted of two full days packed with interesting and informative talks and workshops relating to various aspects of BDD. Speakers included world renowned contributors to the technologies and practices of BDD, including Aslak Helles??y, the creator of Cucumber, and Gasper Nagy, the creator of SpecFlow BDD tools used by tens of thousands of developers world-wide. I couldn't possibly sum up all the content of the workshops and talks that I attended so I'll summarise a few of the key points that resonated with me.

Not all tests that can be automated should be automated. Sometimes an eye-over is enough.

One of the speakers recounted examples of where significant and costly development effort had gone into automating aspects of certain tests that were unlikely to be affected by change, often and could have been, simply and quickly checked manually whenever common sense and a bit of process management dictated that these aspects may be affected. In retrospect, they could have saved themselves a lot of effort had they exercised more moderation in their levels of test automation.

Keep it 'hidden in the given'

In BDD, system behaviours are specified in user stories that are broken down into multiple scenarios which define the behaviour of the system. Each scenario is broken down into 3 blocks;

• 'Given' the initial conditions assumed to be true at the beginning of the scenario
• 'When' the event that triggers the scenario
• 'Then' the expected outcome of the scenario

Each of these blocks can be further broken down into one or more steps describing the given preconditions and the testable outcomes of the scenario, which are then mapped, using tools like Cucumber and SpecFlow, to code stubs. These code stubs allow a development team to transform these human-readable scenarios into a suite of automated tests, testing exactly what the scenario text describes. A real-world scenario may have a myriad initial conditions that need to be set in place before the specific event that is being described. The advice of more than one of the speakers was to automate as much as possible of the setup required within very few 'given' steps to make the scenario as readable as possible. To keep it 'hidden in the given' means to obscure the setup of complex preconditions for a scenario within the test stubs of as few scenario steps as possible rather than have the scenario pre-conditions set up with lots of steps. This makes the scenarios easier to read and understand.

Describe the behaviour, not the implementation

To truly gain the benefits of BDD, one should describe the behaviour of the system without any reference to how the behaviour is implemented. This means that the behaviour is decoupled from the implementation in terms of how it is designed and therefore prevents both technical and non-technical stakeholders from jumping to solution too early. For example, consider the following scenario: Scenario 1: Refunded items should be returned to stock Given that a customer previously bought a black sweater from me And the number of black sweaters in stock on the stock page is 3 And I have selected the black sweater from the return item type drop down list When I click the return item button Then the number of black sweaters in stock on the stock page should be 4 Now consider this re-written version of the same scenario: Scenario 1: Refunded items should be returned to stock Given that a customer previously bought a black sweater from me And I have three black sweaters in stock. When he returns the black sweater for a refund Then I should have four black sweaters in stock. The second example demonstrates how the behaviour can, and should, be described without any reference to how the behaviour is implemented in the system. This is far easier to read in terms of building and maintaining living documentation that describes the behaviour of the system independent of its implementation. This, in turn, supports the good advice of another speaker, Dirk Rombauts. He said that we should avoid anything that;

• Reduces involvement of team members
• Creates information overload
• Reduces outside-in development

This is all because at its core, BDD is centred around bridging communication gaps between the various stakeholders involved in a software development project, creating living documentation which function as executable specifications that provide frequent and rapid validation of the system features.

Design for Failure

Designing a system for failure, though not exclusive to BDD, this was something that came up several times in various talks and workshops at the conference. This is the idea that a system should always be designed in such a way that its ability to respond to things that can go wrong should be priority features, not afterthoughts. For example, an application that relies on an internet connection to complete an operation should be designed so that the way it deals with a connection loss in the middle of that operation should be as important as the design for how it functions when its operations are completed successfully. On the second day of the conference, I was discussing this with one of the speakers, Thomas Sundberg. We got into talking about the problem of ensuring that the same enthusiasm from developers for coding the 'happy path' can be applied in coding the 'unhappy paths' of a system. I said that in software development we have many principles that we use as guidelines for building clean, maintainable, stable code e.g. the DRY Principle (Don't Repeat Yourself), the Single Responsibility Principle, The Dependency Inversion Principle, etc. I suggested that we should bring the term Delayed Gratification Principle into our discourse as a software development principle. Delayed gratification is the ability to resist the temptation for an immediate reward and wait for a later reward. In terms of designing for failure, this applies in the form of coding the unhappy paths first and saving the best part the happy path until the end. This means that coding the unhappy paths are no longer chores that have to be completed before one can move on to the next development story. In my experience, applying this approach has led to an improvement in quality and has made coding even more fun. Thomas was delighted with this and told me that I absolutely must speak about this in the conference. What choice did I have now? I could decline that would be easy. But what is it they say? -We are more likely to regret the things we don't do than the things we do? So I put a few slides together and approached the organisers who allocated me a 10-minute slot in the main hall (in front of hundreds of BDD enthusiasts!!) later the same day. Nervous as I was, my talk was very well received with several people approaching me afterwards to talk more about this concept and its relevance in software development. Overall, the CukeUp 2016 conference was really enjoyable and thoroughly informative. I look forward to seeing growth and continuous improvement in the use of BDD practices in the projects that I am involved in.