3 ms·
I have yet to see a cucumber test that was actually touched by a non-technical domain expert. It is a fantasy and only introduces inscrutable abstraction layers
by MrBuddyCasino 4y ago
I have yet to see a cucumber test that was actually touched by a non-technical domain expert. It is a fantasy and only introduces inscrutable abstraction layers that don’t add value.
- robertlagrant 4y agoIt's not a fantasy. They may not write them (though some less technical manual QA people will add to scenarios with a data table), but deciding on them and reading them, and spitting their results out into documentation are all useful in their own rights.
- hitchdev 4y agoI think this is due to Cucumber's syntax and culture, not because the idea itself is a fantasy. The syntax simply doesn't allow for complex representations of specifications and doesn't have anything resembling inheritance (e.g. add employee story->depends on admin logged in story). I built this tool/DSL on the basis that a more flexible language combined with templated doc generation would bridge the gap better: https://github.com/hitchdev/examples/ https://github.com/hitchdev/examples/
- randomdata 4y agoI have, and that is how they wanted to communicate the needs of the application to the development team. It was horrid. Getting non sequitur snippets of requirements without the big picture, in this weird almost English, but not, language that looked like it was desperately trying to copy the structure of test code, but without anything executable, losing the entire reason you might choose to accept the tradeoffs of documenting your requirements in code as promoted by actual BDD. Not only did it not add value, it took away value.