Agile2014

In many organisations there is mistrust between team members, which has grown out of



* business stakeholders being unable to validate assumptions of the development team until after implementation

* developers delivering buggy/incorrect code despite writing unit tests

* testers writing large, manual test suites that take a long time to run



Behaviour Driven Development (BDD) is a technique that can improve communication between the technical and non-technical participants on a project. In this session you will not simply be told what BDD is, but you will discover how BDD can help (re)build trust between developers, testers and the business and so deliver greater value to your customers.



You will learn why teams start by writing lots of end-2-end scenarios - a Testing Pyramid anti-pattern known as the "Ice Cream Cone". When this causes problems, it is often recommended that some scenarios get pushed 'down' into the unit test suite. The trouble with this is that even if the business folk and the testers trusted the developer's unit tests implicitly (which they often don't ;-) there's still the issue of visibility. We no longer have one complete, generally consumable, source living documentation.



You will learn how to use Cucumber's tagged hooks to control the amount of application stack that a scenario exercises. This lets you tailor your execution context depending on the runtime of the feature suite and the amount of trust the team has to spare. In the limit, this allows you (where it makes sense) to expose some of your unit tests as scenarios - keeping your living documentation complete.