Spock is a new testing and specification framework for Java and Groovy developers. When spreading the word about Spock, I often get the question: "Why on earth would I need yet another testing framework? Aren't there enough xUnit/xSpec clones out there already?" In this post, I'll try to show you how Spock is different, and why it is worth a closer look.
Assertions
Assertions are the most fundamental way to express how a piece of software should behave. It's almost a tradition that every new testing framework comes with its own assertion API, adding a few wrinkles here and there, and naming things a little differently. For example, to say that two things are equal, you would typically write something like:
assertEquals(x, y)x.shouldEqual(y)x.mustBe(y)
Every now and then, a stranger comes along and asks if he can't just use plain boolean expressions instead of an assertion API. But we all know that boolean expressions can't tell us why they failed. Or can they? Meet Spock!
In Spock, assertions come after the expect: label, and are just what the stranger asked for - plain boolean expressions! Here is what we get when we run this test:
Of course this doesn't just work for simple comparisons, but for arbitrary assertions. Here is another, slightly more interesting output:
Again, Spock's runtime has collected all relevant information, and presents it in an intuitive way. Nice, isn't it?
Data-driven tests
Although data-driven testing is a natural extension of state-based testing, it doesn't seem to be used very often. I suppose this is because test frameworks make writing data-driven tests rather hard. All of them? Meet Spock!
The expect block provides just the test logic, using the free (i.e. undefined) variables a, b and c as placeholders for data. It's then up to the where block to bind concrete values to these variables. When this test is run, it is repeated three times: first with a = 7, b = 3, and c = 7; then with a = 4, b = 5, and c = 5; and finally with a = b = c = 9.
Of course, the test data doesn't have to be baked into the test. For example, let's try to load it from a database instead:
Here the values for a, b, and c are taken from the equally named columns of the maxdata table, until no more rows are left. Using a syntax similar to Groovy's multi-assignment, the where block can be simplified even further:
Together with the creation of the Sql instance above, we are now down to two lines of code to load our test data from a database. How easy is that?
Summary
Assertions and data-driven tests are just two areas where Spock achieves more with less. At http://spockframework.org, you will also meet Spock's incredibly lean mocking framework, its interception-based extension mechanism, and other fascinating life forms. If you have any questions or suggestions, please write us at http://groups.google.com/group/spockframework, or file an issue at http://issues.spockframework.org. I'm looking forward to your feedback!
Peter Niederwieser
Founder, Spock Framework
http://spockframework.org
Hello! Some important changes are coming in the newest version of HTTP Builder, and I wanted to get feedback from the community while this is still in development.
I've released an experimental snapshot that includes a prototype REST client API, as well as some breaking changes from 0.4.x. HTTPBuilder is a streamlined HTTP client API built on Apache's robust HttpClient.
First, the good news:
v0.5 will include RESTClient, which aims to make REST operations as pain-free as possible. Whereas HTTPBuilder is optimized to parse streaming response data, RESTClient assumes the response can easily be read into memory. This is how HTTPBuilder's default response handler works currently, but RESTClient goes one step further and provides simplified access to response headers and the parsed data without any inline closure at all.
An Example:
Notice how JSON and XML are used interchangeably, and the response is automatically parsed based on the response content-type header. This API is still in development, so suggestions for improvement are more than welcome!
Now the bad news; breaking changes from 0.4.x...
The main breaking change is that all "url" parameters and named arguments are being changed to "uri." This is mainly because Apache HttpClient uses URIs, not URLs for its operations. So it was inconsistent and misleading to use the term "URL" when in fact, it is a URI. There are a few other minor changes, but they are expected to be low impact. You can see a list of changes for 0.5.0 here.
The HTTPBuilder homepage has not yet been updated, but a snapshot release is available for eager users to test out.
Comments and feedback are welcome. Site documentation should be updated within a week. Enjoy!