[triskweline]

We're heavy users of Cucumber at our development agency. I've never seen non-technical users write Cucumber scenarios either, but we find them very useful for another reason.

The problem with test suites is that, as they grow and age, it becomes harder and harder to understand why tests are testing what they test. When a years old test fails because 5 is not 7, you cannot really fix it unless you understand why it was supposed to equal 7 in the first place.

Cucumber is a way to describe requirements at a higher level of abstraction. They provide rationale on top of mere assertions of behavior. This is worth the small overhead of writing step definitions.

I guess you can get the same by heavily commenting your tests. But you cannot enforce this easily in a team.

[choward]

Nothing is stopping you from using functions with descriptive names without cucumber. Cucumber forces you to write functions (steps) however you can still create bad descriptions just like function names. Cucumber just allows you to define functions using a different syntax than the language your using. I don't see any wins here.

[maxxxxx]

That has been my recommendation when people started talking about Cucumber at my compnay. Write a library that has super descriptive names like "EnterTextIntoPriceField(400)" and you get the same benefit Cucumber gives you but you have real programming language if needed.

Our biz people can't write useful requirements so I doubt they can write meaningful Cucumber scripts either.

[jondubois]

I worked for a very large company that started rolling out cucumber. It didn't go anywhere - Product owners simply did not have the technical ability to write cucumber tests.

I think that they add way too much complexity. It doesn't make sense to try to write technical software tests at such a high level of abstraction.

When you try to test something at a really high level along the lines of "As a user, when I click on X, I want Y to happen" the low level technical ramifications of this can be enormous.

There is a huge amount of underlying complexity which the one-line sentence simply cannot capture and which is prone to change and needs to be tested separately... Probably not in a way that a non-technical manager would understand unfortunately.

Ultimately the tests are not granular enough to be useful as tests for developers and they have too much overhead to be useful as documentation for non managers.