We’ve been supporting our codebase for many years, but we are starting to look into describing our core site tests as a load of Gherkin features. This is the first step as we move to a more highly automated testing process.
Now - what is Gherkin? It’s a way of describing what your application does in a way that anyone from the business can understand. The way the language has been designed it stands as a template that can be understood by testing frameworks. It looks like the following (this example is found on the wiki description:
The idea is to write these for core parts of the site.
Originally I thought it was an easy task. I have a list of core site tests, so I grabbed the list and started on the very first core feature.
That was all I needed to know what to test, but I can’t hand that over to anyone who doesn’t really understand the domain. The objective of writing these features is to make sure anyone can read these specs and understand how to test them, even an automation engine.
As I started to write the tests I realised that Gherkin is far more verbose. You need to describe the exact state in every scenario, look at this.
This was originally described as the concept
But that’s not enough - I also need to describe what “not” being logged in is…
Only once these two tests are satisfied.
As I started to look at all the different scenarios that the user can follow, it quickly escalated to a much more complicated set of scenarios. The problem is, the concept of Gherkin is BDD - Behaviour Driven Development (Or Design). As we haven’t driven the development spec first, we are starting to pay the tax. BDD would have alerted us to all the crazy minor edge cases, and helped us simplify the design.
Where does it leave us? We need to do a lot of work writing our scenarios if we want to cover the core site areas, but there’s no urgent need - we can evolve our existing regression tests into Gherkin over time. Anything we learn we can feed into future developments - ones in which we can start considering BDD upfront.