BDD for Dynamics 365 CE – Part 1 – Intro

Behaviour Driven Development (BDD) and Test Driven Development (TDD) are not terms you often hear when working on Dynamics 365 CE projects. However with the rising interest in adopting DevOps, availability of tools and increasing number of large scale deployments, will these practices become more widely used? I will try to answer this question in this post…

What is BDD?

Essentially BDD is framework that can be applied to software projects to ensure that the delivered product will meet the stakeholders expectations and desired outcome is achieved.

Why use BDD?

Many projects fail because requirements are not clearly specified, also the requirements can get interpreted differently by stakeholders, analysts, developers and testers. BDD ensures requirements are clearly defined and understood by all parties.

Quality issues can arise if implementation and testing is not inline with requirements especially as the system evolves, BDD ensures implementation remains inline with requirements by keeping a constant link between evolving requirements and tests.

How BDD Works?

In BDD you take a user-centered approach to define the behaviour of the system using scenarios and examples. This is defined using a ubiquitous language that can be understood by all parties involved.

Once scenarios and examples are defined and agreed using language specification, the specification is used as a basis for automated testing to ensure that system meets the desired outcome.

What is Ubiquitous language?

It is a language that can be used to describe the behaviour of the system using scenarios and examples. This is the contract between all parties (business, developers, testers) that everyone understands and agrees to.

Gherkin is the most widely adopted language in BDD and it follows Given-When-Then format.

How to describe behaviour using Gherkin?

Below is a simple example of a given scenario. I won’t explain this any further because the whole point of using specification is that things are clearly understood by all parties.

Feature: Introductory phone call

In order to provide excellent customer service
As a customer service
I want to arrange a follow up phone call with new customers

Scenario: New account creation

Given I login to CRM
When I create a new account
Then a phone call record should be created
And due date should be in 5 days

What is the cost?

The team needs to spend some time to get familiar with BDD and agree on using a language like Gherkin. The next step would be to use a framework that can translate these to automated tests that can be written and maintained by developers.

Is BDD Suitable for Dynamics 365 CE projects?

Dynamics 365 CE is a very rich SaaS offering. In fact you can meet many of the user requirements through configuration  without having to write any code. That might mean that you may not even have developers on your team to write the automated tests. BDD may not be suitable for all projects.

When can BDD be useful for Dynamics 365 CE projects?

1. You want to use automated testing to increase quality and reduce regression cycles
2. You want to adopt DevOps methodologies to delivery regular business value
3. You want tractability between requirements, implementation and testing
4. You want to ensure requirements are clearly defined and understood by all parties

Note even if you don’t go down the route of automated testing, there may be still some value you can gain by using BDD specification to define requirements.

Can I see some examples?

BDD may not be suitable for everything, in the following posts I go through several scenario where BDD can add value and show you how you can implement this in practice. You can then decide whether it is something that can add value and help you with your Dynamics 365 CE projects.

Let me know what you think…