Is Cucumber appropriate for expansive corner case specification?

Question

Question

So, is using Cucumber to (near)exhaustively define complex interactions of requirements by example an abuse of the tool?

Question Setup

Is it appropriate use of Cucumber (or any other specification by example tool) for documenting the complex interactions of rules? Global rules in written requirements can leave ambiguities about how they interact with each other. Thus it would be nice to use concrete examples to document this behaviour. And it is important that the client and the human readable nature of Gherkin is appealing. However there is a guideline:

In general if there are more than about five or six scenarios, a story can probably be broken down by grouping similar scenarios together. Dan North

Whereas for any rule interaction there are easily dozens of meaningfully interesting cases to document. Then for any feature you either end up with dozens of scenarios or thinly slicing your features until absurdity until they are no longer recognisable by the client (eg "that's all part of the 'auto-complete & save' button"). It also is not part not an exploratory process of BDD, but documenting rulings from signed-off requirements.

Background

I work at a consulting company that provides customised solutions for configuration management of relatively complex things like industrial trucks where there are lots of options and the rules and dependencies between options are complex. To make matters worse, there are business rules around auto-fulfilling dependencies if the user hasn't explicitly (eg if you don't specify an engine we will select one for you based on your current vehicle tonnage ), and the rules around tie-breaking between which option can be extensive (such as one of the types of options have 7 layers of tie-breakers).

These things are hard to iron out in requirements using general rules, and are huge source of bugs. There are frequently disputes (because rework involves additional billing as opposed to being covered by the maintenance contract) with the client whether something is truly a bug or do they have a change in workflow/business rules/down stream systems that is a change to the system.

---

PS - using a different technology (eg rule engine, Prolog) is not acceptable because it would effect the maintenance contract. It must be a pure Java solution.

PPS - we are not agile, we are waterfall so this isn't exploratory, it's part of a semi-official post-process akin to NAFTA's "Memorandum of Understanding"

PPPS - I looked at whether this question is appropriate to ask here and it feels like it falls under "software development methods and practices" and the other Cucumber questions

Answer 1

-- This answer was written in response to the origional version of the question which read : "So, is using Cucumber to (near)exhaustively define complex interactions of requirements by example an abuse of the tool?" --

I would say not.

As you point out, business rules which interact with each other can lead to unexpected outcomes. I've lost track of the number of 'bugs' which turn out to be simply be unexpected outcomes of two or more business rules being applied. Often the 'bug' is pointed out years after the rules have been implemented and you have no idea if the consequence is intended or not, resulting in meetings and confusion.

Its much easier when example scenarios of rule interactions are spelt in tests. This can get verbose if you write them all out in cucumber, but thats only because of the complexity of your business rules.

Many cucumber frameworks will support data driven tests which can help to reduce and simplify your tests

http://toolsqa.com/cucumber/data-driven-testing-using-examples-keyword/

But I would caution against making your tests overly 'codey', as they will doubtless have to be used in future to explain to non-coders why the system behaves as it does.

I would try and include business justifications in the test if possible. ie

When the engine is not selected
in order to maximise fleet availability
Then the most available engine size should be selected

Is better than

When the |part| is not selected
Then then |expectedPart| should be used

It will mean more tests, because you have that extra sentence which wont apply to all the examples. But will be invaluable in three years time when someone suggests that customers like the biggest engine and its a bug that it is not selected.