Cucumber BDD Testing with TestServer
For development teams using Cucumber to design behavior driven features, stories, and scenarios, there are open source tools to translate your feature and scenario acceptance tests into test recipes that can be executed by TestServer. The practical benefits of this approach are:
- Your Gherkin statements stay implementation free, making them easier to collaborate on
- You have a enterprise-ready approach to translating design statements to API test steps
- You can prove which design documents are testable and which aren't covered in your current testing activities
To automate your Gherkin statements, you need to provide translation between them and practical API test semantics. This keeps your BDD test statements free of code and readable by everyone on your team, technical or otherwise.
What is Gherkin?
Gherkin is the language used to describe features and scenarios in Cucumber, it provides a common way for business stakeholders, analysts, and developers to describe software and write acceptance tests. While the logistics of Gherkin statement structure are roughly the same between implementations, much of the grammar differs project to project. The basic 'Given...When...Then' statements as common terminology allow teams to build their own conditions, actions, and testable outcome descriptions.
How to keep your Gherkin scripts free from JSON?
The problem with making Gherkin and Cucumber act as an API testing solution is that the more you force a collaborative design language to do API testing, the more brittle and less collaborative your scripts become.
Ultimately you'll end up making your once readable BDD test scripts look more like API syntax-ridden code blocks (right), both harder for non-technical people to read as well as brittle when API definitions change.
By separating your design statements from their translation to API testing details, you keep your Gherkin scripts readable and your automated API testing strategy flexible to new statements.
An Example of translating clean Gherkin into Java
Though the 'Given...When...Then' syntax is a standard shared by all Gherkin scripts, your BDD test grammar is entirely up to you. This provides flexibility around what you are designing, the conditions that support your scenarios or features, and the expectations you put on those designs. The challenge is to map your grammar to practical API testing steps.
On the right, you see a Gherkin example statement. This sample describes a 'Given-When-Then' statement about an API named 'swagger-hub' which provides a directory listing endpoint. In this example, the validation check is where your functional API test would assert that a proper response be returned in a gi ven amount of time.
This is a simple grammar for APIs that can be used as a reference point and built upon to fit your own Gherkin grammar. However, the statements you write in Gherkin must be translated to testing semantics, regardless of what framework you run the actual tests on, and Ready! API provides a complete and simple syntax (currently in Java) to bridge this gap.
In fact, you can write this translation layer in any language, though with the inclusion of the TestServer Java client libraries, connecting the dots in code is a bit easier. Here is a sample of the translation layer code in Java:
See the Sample Project
Back To All Features