Writing a parameterized specification in Spock is easy.
We need to add the where: block and use data providers to specify different values.
For each set of values from the data providers our specifications is run, so we can test for example very effectively multiple input arguments for a method and the expected outcome.
A data provider can be anything that implements the Iterable interface.
Spock also adds support for a data table.
In the data table we define columns for each variable and in the rows values for each variable.
Since Spock 1.1 we can reuse the value of the variables inside the data provider or data table.
The value of the variable can only be reused in variables that are defined after the variable we want to reuse is defined.
In the following example we have two feature methods, one uses a data provider and one a data table.
The variable sentence is defined after the variable search, so we can use the search variable value in the definition of the sentence variable.
Continue reading →
We all know writing tests or specifications with Spock is fun.
We can run our specifications and when one of our assertions in a feature method invalid, the feature method is marked as failed.
If we have more than one assertion in our feature method, only the first assertion that fails is returned as an error.
Any other assertion after a failing assertion are not checked.
To let Spock execute all assertions and return all failing assertions at once we must use the verifyAll method.
We pass a closure with all our assertions to the method.
All assertions will be checked when use the verifyAll and if one or more of the assertions is invalid the feature method will fail.
In the following example specification we have 3 assertions in the feature method check all properties are valid.
We don’t use the verifyAll method in our first example.
Continue reading →
Arthur Arts wrote an blog post about Using ArgumentCaptor for generic collections with Mockito. With the ArgumentCaptor in Mockito the parameters of a method call to a mock are captured and can be verified with assertions. In Spock we can also get a hold on the arguments that are passed to a method call of a mock and we can write assertions to check the parameters for certain conditions. When we create a mock in Spock and invoke a method on the mock the arguments are matched using the equals() implementation of the argument type. If they are not equal Spock will tell us by showing a message that there are too few invocations of the method call. Let’s show this with an example. First we create some classes we want to test:
package com.jdriven.spock
class ClassUnderTest {
private final Greeting greeting
ClassUnderTest(final Greeting greeting) {
this.greeting = greeting
}
String greeting(final List<Person> people) {
greeting.sayHello(people)
}
}
package com.jdriven.spock
interface Greeting {
String sayHello(final List<Person> people)
}
package com.jdriven.spock
@groovy.transform.Canonical
class Person {
String name
}
Continue reading →
