Internally in our company, we have various discussions about writing cucumber especially intentions vs implementations.
Surprisingly the business loves the idea of writing cucumber with implementations. For them this is much tighter control. How do you feel about this? Have you had similar experience?
I’ve never been successful in getting business people interested in writing/editing or even reading business test specifications. Do your business people like the idea of writing imperative cucumber scenarios, or actually writing imperative cucumber scenarios?
I personally prefer having discussions with the business about key user scenarios with examples, and then using the information I gather from these discussions to write scenarios that convey the intention of these scenarios and examples.
Tying cucumber scenarios directly to the implementation I have found leads to scenarios that are a lot more brittle to change, and I personally find using patterns like page objects are great for reducing any implementation maintainability overhead as fields/forms/elements implementation detail are stored in one place, whereas with imperative scenarios these are scattered across many feature files/scenarios. For example, I prefer
Given I am a customer from a small company
When I enter my personal and company details
When I enter "Sarah" into the "first name" field
And I enter "Jones" into the "last name" field
And I enter "ACME Corp" into the "company" field
And I click the "order" button
The other benefit of declarative or intention-based scenarios is these can be written before an implementation even exists, so it’s more likely these will emerge before/during software development, instead of being written as a “regression testing catch up” activity after the software already exists.
I’m interested in whether you’ve had success with this, or whether it’s early stages and you’re trying to see if what the business desires will actually work?