Since automated acceptance tests are used to guide development the common belief is that they should be run against an application's full stack. This poses a question for teams that have clear development roles defined such as Front end and Back end developers, who should create and use automated acceptance tests?
The issue is that teams that have clearly defined boundaries struggle to know who should use automated acceptance tests. The front end developer may be responsible for the part for the application the user will be interacting with, but the back end developer may be responsible for the backend logic. If automated acceptance tests are focused on the delivery of the full feature, this leads to issues around who is responsible.
However, developers can be successful with automated acceptance tests that don't run against full stack applications but against the interfaces or boundaries they are responsible for. Tools like Cucumber allow teams to have multiple sets of step definitions meaning you could have one set of step definitions that deal with the UI behaviour and a stubbed backend and another set that deal with the backend behaviour via an HTTP API. All the while they are both driven from the same captured examples in a feature file, meaning both developers are still guided to deliver the right thing.
Leveraging multiple step definitions
A standard setup with a tool like Cucumber looks like this:
As you can see the Feature files are connected to one set of step definitions. However, using advanced features in Cucumber's command line interface we can actually tell Cucumber which specific set of step definitions we want to use.
Both sets contain the same step definitions, but the code inside is different depending on the interface it is interacting with. This means that we have a single point of truth in our feature files which avoids duplicating our feature files across frameworks. But we can still run all our acceptance tests from the same framework across multiple interfaces.
Setting which set of step definitions to run
Check out this demonstration of a multi step project in Java. To execute specific steps run either of the following commands:
mvn test -Dcucumber.options="--glue ui" # Run UI steps
mvn test -Dcucumber.options="--glue api" # Run API steps
Check out this demonstration of a multi step project in Ruby. To execute specific steps run either of the following commands:
cucumber -r features/ui_step_defs # Run UI steps
cucumber -r features/api_step_defs # Run API steps
You can also abstract these command lines into a Rake file
cucumber-js -r features/ui_step_defs # Run UI steps
cucumber-js -r features/api_step_defs # Run API steps
You can also abstract these commands into your NPM package.json