|Cognizant's Peter Rogers|
Behaviour Driven Development
Last year I was in sunny Spain teaching Test Driven Development and this year I have found myself in not-so-sunny Manchester as the Behaviour Driven Development coach. You have probably heard of the prior but the latter may be something slightly new and I would like to share my experiences in this blog.
Test Driven Development (TDD) is great for getting your developers to write lots of unit tests, drive effective code coverage and think about what the code should do before they write it. The problem is that it is still very difficult for designers, developers, business analysts, architects and testers to talk the same language. There is often a communication gap between the developers and the user experience team and there is little mapping back to the original business requirements. Architects use UML (or different flavours of it) as a universal language but it often gets lost on designers and business analysts.
Behaviour Driven Development (BDD) tackles this problem with a multi-purpose business readable domain specific language called Gherkin. This allows you to describe the software’s behaviour in terms of features, without detailing exactly how that behaviour is implemented. This feature-focussed view of the world (sometimes called Feature Driven Development) allows a cross-disciplined team to all talk the same language and work together in a truly collaborative environment.
Gherkin allows us to write automated business acceptance tests from the perspective of the user interacting with the software through the user interface. This creates a top-down set of feature driven tests (often called Scenario Tests or Acceptance Tests) which check how the code integrates together, how the user interface behaves, and that the general business goals of the system are achieved. It also acts as a form of documentation and can be used to help drive the code design through the evolution of a domain model. It has also been designed to work in most languages around the world, so it even allows international collaboration.
Cucumber is the tool that allows us to automate our Gherkin based acceptance tests. Typically a project will aim for 100% coverage of acceptance tests. That does not mean we give up on our unit tests, far from it. The unit tests can either be generated in a top-down approach seeded from the acceptance tests or more traditionally bottom-up to test the actual core software functionality. We use Code Coverage tools in order to check the coverage percentage of our unit tests and typically look for a figure around 80%. If we combine all these tests together with strong quality assurance performed manually then we can start to build world class software.
This may seem like a lot of testing and indeed it is. The important thing to note is that a lot of the testing overhead has moved away from the testers and onto the developers. It is the developer now who creates the unit tests, creates the acceptance tests and who runs the code coverage tools. The testers are left with the manual testing such as:
- quality assurance
- accessibility testing
- functional testing
- performance testing
- security testing
- non-functional requirement testing
- adhoc testing
So what does Gherkin look like? It looks like normal English but with a few keywords that start each sentence. In fact most of these keywords are actually stripped out by Cucumber. We describe a Feature in terms of a number of Scenarios (acceptance tests) which are detailed by the use of the words ‘given’, ‘then’, ‘when’, ‘but’ and ‘and’ – and we rarely use ‘but’.
- Given I want to buy a Playstation 4
- When I visit the Sony Website
- And I go to the Playstation 4 page
- And I enter my credit card details
- And I click the buy button
- Then I should receive confirmation of my Playstation 4 delivery
Here is what a step definition looks like and before you panic the regular expression is automatically generated by Cucumber, but you will probably want to modify it so understanding it is important. The given-when-then statements are transformed into regular expressions which map to Ruby code.
Then /^I (?:press|touch) the "([^\"]*)" button$/ do |name|
The Ruby code uses the Cucumber API in order to achieve its magic. This API offers a UI automation library to interact with the user interface and then check the result. It is designed to be an API that can run on any platform. Obviously each underlying UI automation framework is going to be OS specific and so the Cucumber API is implemented through a dedicated library for each supported operating systems. The whole system is called Calabash and so if for example you wanted to run these acceptance tests on an iPhone then you would look for the Calabash-iOS library.
The step definitions can be quite scary but luckily Calabash comes with a number of predefined steps that you can use. This is a great way to start out but you will soon hit limitations and have to start writing your own. If you want to keep the acceptance criteria in exactly the same language but use the predefined steps (which have a very specific syntax) then you can use macros to map your steps to either predefined or custom ones.
If you wonder how the Cucumber API drives the User Interface then it actually has a tool to find the user interface components on the native platform using a custom query syntax. This syntax relies on accessibility labels in order to find the right UI element. The Ruby script in the step definition is used to call the Cucumber API function which allow you to interact (touch, enter text, swipe, click, etc.) with the relevant UI component. Native system level components like permission pop ups can also be interacted with a lower level API feature set.
The end result is that your natural language acceptance tests are transformed into magically automated clicks, touches and swipes of your user interface in order the test your software meets the required business acceptance criteria. In case the developers amongst you are wondering, you can make Calabash wait for a certain screen to have loaded, before you start to query it. You should end up with a happy business analyst (or two), a happy user experience team, a happy test team, a happy development team and a very tired architect. I mention the poor architect because a solution architect needs to own the solution from a technical perspective and on a BDD project that means - understanding project management tools (like JIRA) and how to fully utilise Gherkin; test tools like Calabash and Code Coverage tools; as well as how the user interface should behave; along with the required mobile operating system libraries; and of course the actual architecture.
Calabash is a thing of beauty and I have never seen such high levels of cross-disciplined collaboration on a project before. I can see all the digital practices and design agencies out there really being able to take advantage and transform their software development practises. The journey starts right here folk so dive in…
In the spirit of collaboration then if you are a more visual person then here is a fantastic video on the subject of BDD and Calabash with lots of practical examples.
Thoughts or comments? Contact Peter Rogers here.
Finally a big favor to ask - Will you take my 3-minute survey on mobile behaviors? It is part of an in-depth mobile consumer behaviors and the retail experience report I am working on.
Writer, Speaker, Senior Analyst
Digital Transformation, EBA, Center for the Future of Work Cognizant
View my profile on LinkedIn
Learn about mobile strategies at MobileEnterpriseStrategies.com
Follow me on Twitter @krbenedict
Browse the Mobile Solution Directory
Subscribe to Kevin'sYouTube Channel
Join the Linkedin Group Strategic Enterprise Mobility
Join the Google+ Community Mobile Enterprise Strategies
***Full Disclosure: These are my personal opinions. No company is silly enough to claim them. I am a mobility and digital transformation analyst, consultant and writer. I work with and have worked with many of the companies mentioned in my articles.