Support Multiple given/setup Blocks

[akefirad]

Is your feature request related to a problem?

It's really hard to write heavy integration tests without multiple given blocks. Either the given block becomes very big and unreadable or one has to use @Stepwise annotation.

We use Spock extensively for our integration tests which cover full flows (e.g. purchase flow: get an offer, place an order, do the payment, generating contracts and documents, send emails, etc etc).
Since all of these tests are real HTTP requests, they are pretty slow (compared to unit tests), some of the steps can be almost a second to complete.
If you wanna keep tests totally isolated, either you have to generate the test data (i.e. putting the offer in the database to be able to place an order) every time for every test (which becomes cumbersome and unmaintainable pretty quickly) or use the existing functionality to get the system into the right state (i.e. call POST /api/offer before calling POST /api/order) which makes the test exponentially slower.
The best alternative at the moment is to use @Stepwise tests (which we do) and it works just fine 👍.

Describe the solution you'd like

Ideally it'd be wonderful to merge different steps of a test into a single test method and avoid using @Stepwise, for two reasons:

1. That means a single spec can cover more than one scenario (AFAIK). Otherwise, if you have multiple scenarios you have to create different specs with different names which make navigation a bit unintuitive.
2. The second reason which is more important is that it's not possible to use @RepeatUntilFailure in @Stepwise tests. We use this nice feature (repeat until failure) a lot to debug flaky tests.
3. Sometimes it's not even possible to merge all "setup" logic into one since some of the interactions might be executed out of order.

More specifically I'm thinking about something like this:

def 'test purchase flow'() {

  given: 'a valid request to get an offer'
    // some test data to get an offer

  when: 'send a request to get an offer'
    // send POST /api/offer

  then: 'response should be correct'
    // assert the response is correct


  given: 'a valid request to place an order'
    // some test data to place an order

  when: 'send a request to place an order'
    // send POST /api/order

  then: 'response should be correct'
    // assert the response is correct

  ...
}

Describe alternatives you've considered

Currently it is possible to merge all steps into one single test, but the challenge is that either you have to make the given block very big or put the "setup" logic of each step in their "when" block which is not quite idiomatic in Spock.

I guess I understand why multiple given block is not supported, but I was wondering if there's a way to address this limitation?
Thanks.

Additional context

No response

[Vampire]

Just to clarify, what you mean is to support given: after then: or exepct:, so like

given:
when:
then:
then:
given:
expect:
given:
when:
then:

right?

[akefirad]

Sorry, yes, something like that. I’ll update the description.

[leonard84]

That means a single spec can cover more than one scenario (AFAIK). Otherwise, if you have multiple scenarios you have to create different specs with different names which make navigation a bit unintuitive.

You can use static inner specs/classes if you prefer to keep everything in one file.

The second reason which is more important is that it's not possible to use @RepeatUntilFailure in @stepwise tests. We use this nice feature (repeat until failure) a lot to debug flaky tests.

I'm not convinced that this is a good enough reason to change the fundamental "grammar" of specifications. Although it seems to be the main one.

Sometimes it's not even possible to merge all "setup" logic into one since some of the interactions might be executed out of order.

I don't understand this reason. Could you expand on what you mean and why it is different when it is in one huge method?

Could you reword your specs so that you can use when instead of given? It seems to be a connected flow anyway. In my experience, it worked fine that way when I had to create longer flows.

def 'test purchase flow'() {

  given: 'a valid request to get an offer'
    // some test data to get an offer

  when: 'send a request to get an offer'
    // send POST /api/offer

  then: 'response should be correct'
    // assert the response is correct


  when: 'a valid request to place an order occurs'
    // some test data to place an order

  and: 'send a request to place an order'
    // send POST /api/order

  then: 'response should be correct'
    // assert the response is correct

  ...
}

[akefirad]

Thanks for the reply.

You can use static inner specs/classes if you prefer to keep everything in one file.

Hm, I'm pretty sure I tried inner classes but couldn't make it work. Let me try again.

I'm not convinced that this is a good enough reason to change the fundamental "grammar" of specifications.

I don't see this as a fundamental change, but I'll leave that to the team to decide. On that note: as things are right now, the logic seem to be broken in the step-wise tests (since it doesn't run the previous steps).

I don't understand this reason. Could you expand on what you mean and why it is different when it is in one huge method?

This is news to me. I think I missed an important point: mocks are moved to the corresponding when clause. This works I guess, but it's not as intuitive as having given, because the subsequent when blocks get a bit crowded.

Anyhow, I guess I can live by this for now if this feature request is not being considered. And sorry for submitting a duplicate issue. Not sure why I missed it while searching.

I'll leave this to you here then. Thanks.

[Vampire]

I'm not convinced that this is a good enough reason to change the fundamental "grammar" of specifications. Although it seems to be the main one.

How about the original inventor wanting to do it, just did not get to it? :-)

spock/spock-core/src/main/java/org/spockframework/compiler/DeepBlockRewriter.java

Lines 181 to 183 in f0f60ab

	// would also want to enforce this for when-blocks, but unfortunately it's not that uncommon
	// for projects to have interactions in when-blocks (Gradle, Tapestry). Before we enforce this,
	// we should at least support multiple setup-blocks.