« Table of Contents »
Previous « Reuse Steps, If Possible
The Behaviour Specification Handbook
Effective Behaviour Specification Steps
Understand Technical Tool Constraints
At the end of the day, the developers and/or testers must be able to successfully implement the Behaviour Specifications as automated tests. If they cannot do so because of reasons related to the technical tool that enables the execution of the Behaviour Specifications (e.g. Cucumber, SpecFlow, etcetera), then either the style of writing the Behaviour Specifications must be altered or the tool must be changed.
There is a constraint with the tool Cucumber that may prevent a team from following some of the recommendations in this handbook. With Cucumber, each step within a set of feature files that are executed together is unique and only can have one corresponding implementation. Because of this, when using Cucumber, there cannot be Behaviour Specification steps with the exact same wording in more than one feature file, and with different implementations that are specific to the context of their software component. For example, it would not be possible to implement the suggested approach of having different feature files for the different User Interface mechanisms of voice or touch. With Cucumber, in order to make the wording of each step unique, there would be no choice but to embed specific technical implementation details into the wording of each step, so that each step can be precisely implemented as necessary. The other alternative would be to execute the feature files separately — but for the example of voice and touch interfaces, that does not seem like a good approach since they all relate to the same logical grouping of functionality.
This constraint is an intentional design decision made by the Cucumber development team, with the idea that it forces the usage of a ubiquitous language and fosters better reusability and clarity of steps. Here is one discussion about it, in case you are interested. However, defining more precise steps (in most cases, by specifying implementation details) with the goal that it increases pressure to grow a business’s ubiquitous language (more than likely with technical terminology) is not, in my opinion, a desirable goal or outcome.
The approach I recommend both embraces and highlights the context of a software component and feature file as the key to understanding each behaviour, and also strongly emphasises the usage of an accepted everyday business language. This also probably is another reason that many common behaviour examples follow practices that I do not recommend, because the idea of context is either not well understood or not embraced.
The Cucumber Backgrounder interestingly goes so far as to say that relating the step definition files to specific feature files is considered an anti-pattern – although quickly and wisely advises that you may depart from that advice when you are experienced enough to evaluate the trade-offs. Over the years I have given this a great amount of thought, attention and real-life practise, and with the guidelines in this handbook, I have witnessed many more benefits than negatives. Unfortunately, Cucumber does not appear to be the right tool for the job. There are however other suitable tools available.
In the world of Ruby, Turnip partly was created because of a desire to have step implementations scoped to behaviours.
In the .NET world, the open source tool SpecFlow provides the test automation developer with the option of reusing existing step implementations where useful and desired, and also the ability to have different implementations for the same step wording in different feature files. This choice is made in the implementation code via SpecFlow’s “scope” mechanism, based on criteria such as the title of the feature or “@tags” that are specified at the top of the feature file or on each individual Behaviour Specification.
I strongly recommend the usage of a tool like SpecFlow because of this enabling capability that allows experienced people to make their own choice, without being forced to push a square peg into a round hole. Having said that, many kudos must go to the Cucumber team for their continued effort and dedication over the years, and the community they have inspired.