That shouldn’t have happened

March 20, 2019
That shouldn’t have happened

How many times have you heard this from your development teams? Modern systems are increasingly complex and often suffer from the butterfly effect of small changes. All too often the approach to testing is still highly manual and hasn’t kept pace with that complexity.

The solution? Automated testing. Automated testing discovers if critical functionality works, confirms the system functions from the users’ perspective and gives us confidence that changes haven’t inadvertently broken some far-flung corner of the system.

The approach Quantifeed has adopted is called Behaviour Driven Development or BDD. BDD is a process that aims to describe the behaviour of a system using the ubiquitous language of the domain, in our case the finance industry. BDD has two main areas of focus:

  1. Collaboration: This process involves multiple stakeholders and their understanding of the project. Getting the right people in the same room from the beginning and throughout the process fosters strong communication, a shared understanding of the requirements and engagement in the product development cycle.
  2. The End User or stakeholder: BDD puts the customer’s vision in mind first and focuses on the user’s view of how the application should behave.

The result of the BDD process is a set of examples that we document in a human readable, yet fixed, format and then automate as tests. That fixed format is called Gherkin, the syntax of which is surprisingly simple.

Given a predetermined starting point

When something happens

Then verify the outcome

Given the client has created a portfolio

When the client tops up their portfolio with additional funds

Then buy order should be generated

Using this format, we can describe any functionality in numerous small and easy test cases. These test cases, or ‘scenarios’, will accurately describe the behaviour of the entire system. Moreover, as these scenarios are automated, we can run them again, and again, virtually free of charge. In fact, every single code change will result in all the scenarios being executed in minutes. So within minutes we know whether a change has inadvertently caused an issue, or alternatively whether our application works, and can be potentially deployed into production. This is very powerful and will eventually:

  1. Enable a faster time to market
  2. Ensure issues are found early in the development process.
  3. Speed up the feedback loop between developers and users.
  4. Enable us to scale quickly and efficiently.
  5. Increase productivity.

BDD has one last trick up its sleeve. Because the requirements are automated, they form the system’s living documentation. Change the system but not the tests and the tests will fail. Change the tests without changing the system and, again, the tests will fail. This tight relationship between code and tests, forces us to keep the two in sync. Goodbye to outdated documents lying in half-forgotten document repositories, waiting to confuse whomever has the misfortune to stumble across them!

That’s it: a brief introduction to BDD and how it is transforming many areas of our organization, from how we interact with clients, to how we develop, to our ability to release features more efficiently. Embracing BDD really is a positive game changer for Quantifeed!