Behaviour Driven Development (BDD) – Closing the loop on a Great Fiori UX

When developing Fiori applications using agile we often find a disconnect between

• The business being able to articulate the desired outcomes of the application
• The developers and testers understanding what needs to be built and tested
• The business understanding the technical challenges in meeting their requirements

this blog investigates a collaborative approach to bridge the disconnect.

TL;DR

Software development is a team sport, involving developers, testers, business analysts, users and other stakeholders. To ensure a shared understanding, we find we need to adopt a common language all members in our cross functional teams understand, especially when it comes to defining what we are building and how we are validating it.

Behaviour Driven Development (BDD) is an outside-in approach to software development, we describe what we want our applications to do by talking through many examples of its desired behaviour. These examples are captured as acceptance criteria in a simple consistent language, and they are often turned into automated tests we use to frequently validate what we have built.

By specifying the expected behaviour of our application before developing and using this shared understanding as the basis for automated tests, we not only eliminate the chance of confusion, we increase the business value, the quality of our code and the velocity of delivery, we also reduce a lot of the friction, complexity, bugs, rework and general waste associated with ambiguous requirements.

Objective

Last year at Las Vegas Teched 2016 I gave a talk with the same name, at the time I promised to write a blog on the subject, better late than never.

Behavior-driven Development with Gherkin is a hidden feature of SAPUI5 and Fiori development and not many people have heard of and I think they should. In this blog I will walk through the simple example I gave in my talk and share with the help of the slides, the process and benefits of practising BDD.

Start with the end in mind

http://jasper07.secondphase.com.au/ui5bmi/webapp/test/integration/OpaTests.html

The example app above written using SAPUI5, it calculates your Body Mass Index, BMI is a widely used measure to find out whether you’re a healthy weight for your height.

The app is very simple, an input form captures height and weight, some business rules that calculate the BMI and a custom control to communicate this back to the user.

The Opa5 integration test framework is seen running through various examples of Height and Weight and validating the calculated values are what is expected.

It starts with a conversation

The user story for providing such a feature might look something like.

Depending on which flavor of agile it maybe the Customer, Product Owner or BA who captures the needed feature, user stories are usually written on a card, placed on a wall for all to see, and act as a reminder for a future conversation about a needed feature.

Before the user story is “ready” to be worked on it needs to be discussed, in Scrum this could be part of your backlog grooming or sprint planning. The customer describes what they want and the developers ask questions to flesh out enough detail about the behaviour to be able to code it. Together with the tester they can then run through many real world examples to derive the scenarios which need to be tested before the story is accepted as “done”.

In the case of the BMI app we would quickly come up with real world examples which cover all  the weight categories, under weight through to obese.

Based on the conversation and example scenarios above everybody would have a fair idea of how the app would behave and what the acceptance tests would look like when run.

http://jasper07.secondphase.com.au/ui5bmi/webapp/

Automate the boring stuff

As I mentioned above SAPUI5 supports Behavior-driven Development with Gherkin not only is it comprehensively documented but there are some very cool examples the best examples are hidden like Easter eggs.

For the BMI app the Gherkin feature file, our executable specification looks like

Feature: Calculating Body Mass Index
  As a health specialist
  I want a BMI Calculator
  So that I can calculate patient's Body Mass Index

  Background:
    Given I start my App

  Scenario Outline: Calculate Body Mass Index
    When on the calculate page: I enter <HEIGHT> as height
    And I enter <WEIGHT> as weight
    And I press the Calculate button
    Then on the calculate page: I should see <BMI> as bmi and <CATEGORY> as category
 
  Examples:
    |HEIGHT |WEIGHT |BMI |CATEGORY   |
    |170    |50     |17.3|Underweight|
    |181    |80     |24.4|Normal     |
    |180    |90     |27.8|Overweight |
    |175    |100    |32.7|Obese      |

https://github.com/jasper07/ui5bmi/blob/master/webapp/test/integration/CalculateBMI.feature

Gherkin is not only business readable, it is also supported by many platforms and tools, in theory the same feature file you use for Opa5 Integration Tests which run on mock data, can also be used to run live End-to-End Fiori Launchpad tests, verifying our app works across a wide number of devices and web browsers, tools like Selenium, Google Protractor, HP Lean FT, MS TFS, Sauce Labs etc. can be set up as part of you Continuous Integration pipeline.

Why aren’t you automating everything?

I hear many objections to writing automated tests, mainly I am told it increases development time, what i find with Opa5 tests is once you get over the initial learning hurdle and have built up a library reusable common routines, the effort is reduced considerably, if you factor in the time it takes to regression test and the time saved on boarding new developers, automating your tests pays for itself many times over.

I have been asked a few times by testers, if you automate the tests wont we be out of a job? On the contrary the role of tester in agile is less reactive and more proactive. Instead of concentrating finding bugs, they are tasked with identifying and mitigating risks early, getting more evolved in the design and planning the processes and acting as a conduit between the customer and developer, ensuring quality work can be delivered quickly.

Everythings covered

In summary BDD aids in closing the loop on agile software development, by focusing on the expected behaviour and defining automatable acceptance criteria before we start development, we ensure every piece of delivered software meets the intentions of the users, delivering business value faster.

From a development perspective, less code, cleaner code, fewer mistakes. Automated acceptance tests are a by product of good design, the tests themselves become living documentation, a good place to start if you want to how what your Fiori application does and confidence in knowing you can easily refactor or extend without breaking something in production.

Links

UI5BMI app on github