Why are Spock Speck tests so wordy?

321 Views Asked by At

Coming from JUnit background I don't really understand the point of all the text in spockD tests, since they don't show on the output from the test.

So for example, if I have a constraint on a field Double foo with constraints foo max:5, nullable:false

And I write tests like this:

void "test constraints" {
   when: "foo set to > max"
     foo=6D
   then: "max validation fails"
     !foo.validate()
   when: "foo is null
     foo=null
   then: "null validation fails"
     !foo.validate()
}

The test is well documented in its source, but if the validation fails, the error output doesn't take advantage of all this extra typing I've done to make my tests clear.

All I get is

Failure:  |
test constraints(com.grapevine.FooSpec)
 |
Condition not satisfied:
f.validate()
| |
| false    

But I can't tell form this report whether it failed the null constraint or the max constraint validation and I then need to check the line number of the failure in the test source.

At least with JUnit I could do

foo=60D;
assertFalse("contraints failed to block foo>max", f.validate());
foo=null;
assertFalse("contraints failed to block foo=null", f.validate());

And then I'd get useful info back from in the failure report. Which seems to both more concise and gives a more informative test failure report.

Is there some way get more robust error reporting out of Spec that take advantage of all this typing of when and then clauses so they show up on failure reports so you know what actually fails? Are these "when" and "then" text descriptors only serving as internal source documentation or are they used somewhere?

1

There are 1 best solutions below

2
On

Block descriptions are mostly meant for higher-level tests; they are rarely used in unit tests. That said, there are several third-party reporting extensions for Spock:

At least some of these will output block descriptions as well. Furthermore, it's planned to ship advanced reporting out-of-the-box with the next Spock version.

Instead of having one test check two unrelated cases (as in your Spock/JUnit example), it's generally better to have a separate test with a descriptive name for each case. Spock's data-driven tests can help with this.

While it's possible to add a description for a Spock condition (e.g. assert 1 == 2, "not quite"), I almost always prefer the default "power assert" output.

To answer your title question, well-written Spock tests are typically a lot less wordy than JUnit tests.