Classical unit test as Groovy Spock method - unit-testing

Question

I have a Groovy Spock method that has the following pattern:
def "My test"() {
def a = createA();
assert a.fieldLevel1.isValid()
def b = a.fieldLevel1
assert b.fieldLevel2.isValid()
def c = b.fieldLevel2
assert c.fieldLevel3.isValid()
...
}
As you can see it's hard to break it on blocks as assertions and variables definitions are mixed together. What would be the "spock" approach to write such kind of test?
UPDATE:
The test has the following structure because c.fieldLevel3.isValid() is actually c.fieldLevel3 instanceof A, so I can't proceed if the field is invalid.

Answer 1

The "classical" way of unit testing is keeping tests unitary. That is, testing one thing per test, which seems not to be the case in this example.
That being said, however, you could group all the assertions in an expect block after all the setup code in a setup block:
def "My test"() {
setup:
def b = createA().fieldLevel1
def c = b.fieldLevel2
def d = c.fieldLevel3
expect:
b.valid
c.valid
d.valid
}
Notice that i've shortened the assertions by using Groovy's goodies to access isValid() as valid and calling that method on the auxiliary objects directly.
Also, i haven't used the usual when/then Spock blocks because this test case doesn't seems to align very well with being a stimuli/response on a given system. But you could also use many when and then alternated blocks if you so desire:
def "My test"() {
when: def b = createA().fieldLevel1
then: b.valid
when: def c = b.fieldLevel2
then: c.valid
when: def d = c.fieldLevel3
then: d.valid
}

Answer 2

Not sure why you did not accept the answer above it looks quite good.
As a minor difference, you could also do:
def "My test of creating an A"() {
when:
def a = createA()
then:
a.fieldLevel1.isValid()
a.fieldLevel1.fieldLevel2.isValid()
a.fieldLevel1.fieldLevel2.fieldLevel3.isValid()
}
Whether or not you 'like' this depends upon how closely you follow Demeter's 'Law' - Groovy seems to make that less relevant than in the past.
If the complexity of the actual underlying objects is such that this is not an effective approach at validating them, then they might deserve their own Unit Tests.