Who is this For - RiverGlide/CukeSalad GitHub Wiki
The key role we use to focus the features of CukeSalad is Stephan - the Step Free Cuker. Stephan has found the Roles-Goals-Tasks-Actions pattern useful in expressing his understanding of features and related scenarios. He also wishes for his team to solve/avoid these key problems:
- Over-wordsmithing scenarios
- Limited regular-expression expertise
- Unmaintainably large step-definition files
- Fragmented step-definition files
- Coverage vs. Speed tradeoffs of running scenarios through or below the GUI (respectively)
Stephan wants his feature specs to be quick to write, covering the key factors (Role, Goal and Tasks). He wants a structure that encourages the team to focus on the words used to express these key factors and not on the grammar that surrounds these concepts.
Stephan wants the scenarios to be easy to read, easy on the eye and deliver the right amount of consistency. He wants to be able to quickly express his understanding of the user-story in the scenarios with the minimum friction.
Some team members are quite good with regular expressions but others are not. Stephan and his team mates feel reliant on these people and this can sometimes introduce a constraint into their process.
Stephan wants more people in the team (including Business Analysts, UX Designers and Testers) to be able to contribute and collaborate on expressing the interactions with the application (normally found inside the step-definitions).
Stephan has seen many step-definition files become unmaintainably large making it hard to find where to make additions or changes when new steps are required. This often results in people quickly adding new steps when adapting an existing step would be the better solution. This is resulting in duplication and therefore increased maintenance overheads.
Stephan wants the files that explain the direct interactions with the application to be focused, concise and easy to understand.
Stephan has seen some people try to solve the problem of large step-definition files by splitting step-definition files up in various ways. Some by 'theme' some by 'role'. This can result in lots of step-definition files without a clear way of knowing which step-definition file corresponds to a specific step in a scenario. It also makes it harder to re-use steps across these files due to scoping of variables.
Stephan wants an easy to understand pattern for where to find the code that defines what happens in a specific step. Stephan also wants to easily reuse this code anywhere in his scenarios or from other step-defs.
Stephan has found that driving the scenarios through the GUI takes a lot longer than driving them via the back-end APIs. He has found between 10-fold to a 100-fold speed improvements by driving the interactions through the API. This speeds up the feedback when the core business value is broken. However, he has sometimes later found that, although the business capability is implemented internally, the testers find that it is not possible to access that business capability via the GUI - making it far less valuable.
Stephan wants his team to be able to easily run scenarios through the GUI or below the GUI so that they can enjoy the best of both worlds - speed and coverage.