Spock: Allow multiple where-blocks to enhance readability options

[robfletcher]

Originally reported on Google Code with ID 321

See example gist for illustration of a multiple where block use case: https://gist.github.com/cathalking/76fd9ad59a38b6910f03

Discussed at: https://groups.google.com/forum/#!topic/spockframework/yQPPjpf9spE

The specific usage I have in mind for this enhancement is related to:
(a) Enhancing readability of especially "wide" where blocks e.g. imagine my example
where block below, but with another few columns added. It will quickly disappear off
the screen. By allowing multiple where blocks

(b) Supporting the notion of having separate where "input" and "expectation" blocks.
Again primarily to enhance readability when both the number of inputs and number of
expected values is high. Or simply an extra option rather than using double pipe ||
(which is an elegant feature for small blocks)

(c) Gherkin/Cucumber supports the notion of separate data tables e.g one for Given,
one for When. Which to my mind is a good and useful thing. But then AFAIK you are forced
to process the entire table in a single pass. I'm not so keen on that. Spock thankfully
"feeds" the table/where-block in row-by-row. Adding additional where blocks would emulate
the separate data table feature whilst maintaining the desired row-by-row flow.

where: 'Login inputs + Expected Login greetings are:'
login               | password ||   expectedFullName    | expectedLastSeen  | expectedRepPoints
'[email protected]'   | '123'    ||   'Ralph Malph'       | '20130619'        | '15'
'[email protected]'  | '234'    ||   'Potsie Webber'     | '20130617'        | '19'
'[email protected]'  | '456'    ||   'Richie Cunningham' | '20130613'        | '21'

Proposed multiple where block layout:
// With a "multiple" *where* block approach the single block is essentially broken
up (an arbitrary number of times 
//  where: 'Login inputs'
//  login               | password
//  '[email protected]'   | '123'
//  '[email protected]'      | '234'
//  '[email protected]'  | '456'
//
//  where: 'Expected Login greetings'
//  expectedFullName    | expectedLastSeen  | expectedRepPoints
//  'Ralph Malph'       | '20130619'        | '15'
//  'Potsie Webber'     | '20130617'        | '19'
//  'Richie Cunningham' | '20130613'        | '21'

Reported by cathalking1 on 2013-07-14 20:07:50

[timotei]

Hi. Any feedback on this?

[JordanMartinez]

Yeah. Any feedback?

[footmanFF]

Any feedback?

[ptitcoutu]

I would be interested too

[leonard84]

If we did this, we should probably use and to be more in line with the rest of the blocks.
The AST transform that collects the blocks would first have to concatenate all the data tables, so that the other transforms work as usual.

[fvanwesterop]

Yes, it would be really nice to be able to split, say inputs and expected outputs in separate blocks:

where: 'inputs are'
(...)

and: 'expected outputs are'
(...)

But sometimes you would like to break down inputs into logical groups too, e.g. in a block containing responses from mocked collaborators (e.g. configure a database stand-in) and a block of actual inputs to your test-subject:

where: 'inputs are'
(...)

and: 'mocked database contains'
(...)

and: 'expected outputs are'
(...)

The thing is: On one hand it seems to be a code-smell if you really need a whole lot of inputs to drive your test: It might mean your test-subject just has too many responsibilities. But on the other hand: When in fact you are writing an integration test, where you also need inputs as canned responses of your mocked-out collaborators, _and also_ having multiple results to asserts, _and also_ give descriptive (so slightly longer) names to all your input/output columns you quickly run out of horizontal space on your screen...

It would really make a big difference in terms of usability if you could split the where-block. This would make Spock's parameterized tests far more powerfull than they already are (which is Spock's killer feature anyway IMO). I'd really love this feature :-)

[Vampire]

I think this is covered sufficiently now by my changes that allow multiple data tables which is included in 2.0-M3 already: http://spockframework.org/spock/docs/2.0-M3/all_in_one.html#data-tables