There is a REST service that we test with cucumber, using cucumber.js. The first implementation was very REST oriented. Reuse of the tests for the user interface was pretty much impossible because the tests were technical, not functional. For that reason we label non functional tests cucumbersome.
This is an example of the first technical oriented tests:
@events
Feature: Fetch the root document
As an API client of the Eventr API
I want to fetch the events listing documentScenario: Get the events root document
When I GET the path "/events"
Then the http status should be 200
And the value of total_rows should be ">= 0"
And the value of offset should be ">= 0"
While this is pretty easy to implement, and it does it's job, it mostly resembles the unit tests already in place.
Better is to rewrite the test focussing on the functionality, for example:
Scenario: Create a new event
Given there are 0 events
When I create a new event
Then there will be 1 event
And even more functional:
Scenario: Buy tickets
Given There is an event with name "ASAS 2014" with a ticket price of 200 EUR
When I buy 2 tickets
Then I will have to pay 400 EUR
The REST implementation is done and working fine. If you are interested, check out the code gists for world and step definitions.
Our next challenge is to reuse the tests for the user interface using zombie or the likes.