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 specifications into test recipes that can be consumed 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 statements free of code and readable by everyone on your team, technical or otherwise.
Separating Design Speak from Translation Details
Gherkin, the language used to describe features and scenarios in Cucumber, provides a common way for business stakeholders, analysts, and developers to describe software. 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.
Keep Your Gherkin Scripts Clean 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 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.
Example: Clean Gherkin and Java Translation
Though the 'Given...When...Then' syntax is a standard shared by all Gherkin scripts, your BDD 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.
See the Sample Project
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:
Back To All Features