Lately, I've been playing around with embedding Mule in Tomcat. To get going, I wanted to start with creating an extermely simple service, and along the way I decided to try out the Spock specification framework to test the logic I'd be using in my service. I liked what I found so much, I thought I'd take a little detour and write about my first use of the framework, comparing it to more a common test class, and save the Tomcat posting for another day.
The simple service that will eventually be developed will take a list of numbers and add them up. Here is the class that will ultimately do the math:
class Adder {
Integer add(List<Integer> numbers) {
println "adding: $numbers"
numbers.inject(0) { sum, item -> sum + item }
}
}
The add method takes a list of numbers and returns their sum. I'm using Integer as the return type and List on the parameter declaration instead of the def keyword to aid in the generation of the service WSDL down the line. While the println won't make into the final version of the class, it might help us out demonstrating what is being sent to the method during testing.
With Spock we'll be writing a specification that describes the behavior of the Adder class:
- Given a list of numbers, they should be added together to produce a sum.
- Given a list containg no numbers, zero should be returned.
The framework's documentation does a great job explaining how to write a spec, so I will not to try and reproduce much of it here. The spec is pretty much self-explanatory, each of the two requirements manifests itself in a method:
import spock.lang.*
class AdderSpec extends Specification {
def adder = new Adder()
def "numbers should be added together to produce a sum"() {
expect:
sum == adder.add(numbers)
where:
sum | numbers
4 | [2, 2]
6 | [1, 2, 3]
10 | [1, 2, 3, 4]
1 | [0, 1]
0 | [0, 0]
}
def "summing no numbers at all should return zero"() {
expect:
sum == adder.add(numbers)
where:
sum | numbers
0 | []
0 | null
}
}
The where clauses resemble a table, with each entry describing the input to the add() method on the right, and the expected result on the left. The first entry in the first method would have the values for sum and numbers substituted into the expect clause so that it would read:
4 == adder.add([2, 2])
The output from the test run helps illustrate how things are added during a run of the spec:
Running org.prystasj.services.adder.AdderSpec
adding: [2, 2]
adding: [1, 2, 3]
adding: [0, 1]
adding: []
adding: null
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.091 sec
If the value for numbers instead read [2, 3], we would get the following failure when we run the test as 2+3 does not equal 4:
Condition not satisfied:
sum == adder.add(numbers)
| | | | |
4 | | 5 [2, 3]
| org.prystasj.services.adder.Adder@969c29
false
While I could of used a helper method to remove the redunduncy between the two expect clauses, I liked this output such much, I decided to keep it, as using a method here would modify the resulting failure description. For example:
check(sum, numbers)
| | |
false 4 [2, 3]
Compare the above spec class to a more traditional unit test and see what you think:
import org.junit.Before
import org.junit.Test
import static org.junit.Assert.assertEquals
class AdderTest {
def underTest
@Before
void setUp() {
underTest = new Adder()
}
def verifySumsFor(data) {
data.each { sum, numbers ->
assertEquals "$sum <= $numbers", sum, underTest.add(numbers)
}
}
@Test
void test_numbers_added_together_produce_a_sum() {
def data = [
4 : [2, 2],
6 : [1, 2, 3],
10 : [1, 2, 3, 4],
1 : [0, 1],
0 : [0, 0],
]
verifySumsFor(data)
}
@Test
void test_summing_no_numbers_at_all_should_return_zero() {
def data = [
0 : [],
0 : null,
]
verifySumsFor(data)
}
}
Which version do you like better? Thanks for reading.