What is behaviour-driven development (BDD) and how can we use it to improve the quality of our Microsoft Dynamics 365 and Power Platform apps? Join my free Agile Foundations mini-course: https://customery.com/foundations.
-- Behavioural test is an acceptance test written in plain language that users can write and understand
-- Explain the context, event and outcome in given-when-then format
-- Can be written before, during or after development
-- Writing behavioural tests before development is BDD (behaviour-driven development). Helps developers know when they're done.
-- Set of behaviour tests is a form of contract between users and app builders
-- Can be slow to execute until automated and don't reveal root cause
Neil Benson
LinkedIn: https://linkedin.com/in/neilbenson
Customery: https://customery.com
Customery Academy online training: https://customery.academy
Amazing Apps podcast: https://customery.com/listen
Transcript
The best way to learn about behaviour-driven development is with an example. Here’s one for logging into to Power Apps:
Given the user has access to the environment, and has a security role, and the environment is not in admin mode, and the user is using a supported web browser; when the user visits the application’s URL; then the application default page should load in the user’s browser.
One of the features of a behavioural test is that the test is written in plain English. The test could have been written by, or at least be understood by, one of your application’s users.
You might have noticed that the test has three parts. These are referred to as the context, event and outcome, also known as given, when, then.
The context is the set of conditions that exist at the start of the test. The event is the action that the user takes. The outcome is the expected result. It describes the behaviour of the application when the event happens.
I ride a motorbike to visit my client’s offices. Here’s a behavioural test for starting my motorbike:
Given the battery is charged, there is fuel in the tank, the security fob is near the bike, the ignition switch is on, the engine stop switch is off, the brake lever is pulled, and the side stand is raised; when the starter button is pushed for two seconds; then the motorbike engine starts and idles at 1000rpm.
Behavioural tests describe the expected behaviour of your application in a very direct way. The set of behavioural tests available describes the expected behaviour of the application and forms a contract between the application’s makers and users about what the application should do.
If all the tests pass, then the application is behaving as expected.
If any of the tests fail, then there is an issue that the maker needs to resolve.
We can write behavioural tests for an application at any time.
You could write them before you start developing the feature. The behavioural test is the acceptance criteria for the requirement, for the user story if you’re using user stories to capture the essence of your requirements. This is behaviour-driven development because the behavioural tests inform the application developers about what’s expected so they know when the feature is done.
All the behaviour tests will fail until the feature is complete. When they all pass, then the feature is done. Developers like to know when they’re done, so a benefit of behaviour tests is that developers can stop development and review the feature with the product owner as soon as the test passes. The temptation to embellish the feature with extra bells and whistles is diminished, so developers become more focused and efficient.
You can also write behavioural tests during development. Although this can become tricky if the behavioural tests are much more challenging than the developers assumed when they estimated the requirement’s complexity.
You can also write behavioural tests for an existing application after development has been completed, which can be useful for running regression tests during an upgrade or migration. Contrast this with unit tests, which are much harder to write for an existing application.
The plain, business language of the tests means that they can be written by your product owner, your application users or a business analyst without a lot of training. Professional testers and quality analysts can easily write full-blown test cases from behavioural tests. Automation testers can use a behavioural test as an input for developing an automated test.
Behavioural testing has two drawbacks that are worth keeping in mind. Running behavioural tests is very slow. Once they pass, the test can be automated, but until then it must be run manually. Behavioural tests rarely reveal the root cause of an issue in the same way that a unit test does.
If my motorbike doesn’t start, I have to check seven preconditions and that I was taking the correct action in order to get the expected result. Troubleshooting what went wrong can be slow.
Keep sprinting!
