4 ms·

> It's that other people won't understand you. I think the idea is the other way around. It's not about inventing a new language, it's about taking a jargon th

> It's that other people won't understand you. I think the idea is the other way around. It's not about inventing a new language, it's about taking a jargon that already exists, is used and understood by domain experts, and make it executable. Less regex/XML, more nouns and verbs from a very specific business context. Granted, even with that perspective, it's still a stretch to say little languages are the future, but both the article linked here and the one it's replying to are from 2004, so, there's that.

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 ago
  It'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 ago
  I 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 ago
  I 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.

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 ago
It'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 ago
I 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 ago
I 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.