Ad-Hockery

ad-hockery: /ad·hok'@r·ee/, n.
Gratuitous assumptions... which lead to the appearance of semi-intelligent behavior but are in fact entirely arbitrary. Jargon File

Articles tagged ‘spock’

Testing the RxJava poller

Yesterday I posted about an implementation of a simple remote service polling mechanism using RxJava. One of the things I particularly liked when applying this pattern at work was how straightforward it was to unit test.

Often when dealing with asynchronous processing unit testing can be pretty painful. Typically you need to use a mechanism such as Java’s CountDownLatch or Spock’s BlockingVariables or PollingConditions to synchronize threads before making assertions. Allowing processing to run asynchronously, especially when testing scheduled activity can make tests very slow as well.

Ideally tests the asynchronous nature of the code is abstracted and the timer can be faked out. This is exactly the approach that RxJava takes.

Read more…

Multiple interface mocks with Spock

Spock’s Mock factory method (as well as factories for the other types of test double; Stub & Spy) accepts a single interface representing the type you need a test double for. But what should you do if you need a test double that implements multiple interfaces?

Read more…

Spock and Hamcrest

Groovy’s power assert and Hamcrest matchers both solve a similar problem – getting decent diagnostic information from an assertion failure. When writing JUnit or Spock tests in Groovy it’s typical to not use Hamcrest matchers as the power assert is so much simpler and just as effective. It’s worth bearing in mind, though that Hamcrest is also for helping clearly express the intent of an assertion. Spock provides support for Hamcrest matchers and I recently ran into a situation where I think it was the right thing to use.

Read more…

Stateful interactions in Spock

The Java mocking library jMock has a nice feature for dealing with verifying mock interactions in stateful circumstances. I first came across it when reading Growing Object-Oriented Software Guided By Tests (GOOS) by Steve Freeman & Nat Pryce.

I was curious as to whether I could implement something similar with Spock. There’s no syntactic support right now (although there is an open issue) but it’s not that complex to achieve something adequate.

Read more…

Derived values in Spock where tables

When using where blocks in Spock there are two forms; assigning iterable values to a variable, e.g. crew << ['Mal', 'Kaylee', 'Jayne'] or using a datatable. In the first form I always knew you could use assigned values, for example:

where:
crew << ['Mal', 'Kaylee', 'Jayne']
nameLength = crew.length()

Note the assignment operator used rather than the left shift on the second line there.

Read more…


Testing callbacks with Spock mocks

I’ve been doing some work with vert.x over the last few days and trying to develop components that are test-driven. Like any asynchronous framework rather than having methods that return a value you pass a callback Closure that gets invoked at some point in the future with the result. This makes it tricky to write unit tests that mock out collaborators as you might in a traditional app.

Read more…

Spock Killer Features: The “old” method

I use Spock almost exclusively to test Groovy or Java code these days. It’s got some fantastic features that other test frameworks don’t have. Some of them aren’t that well known or documented, though.

The old method is possibly my favourite Spock feature. It’s a simple thing but really enhances test legibility. It’s also great for wowing developers new to Spock because it looks like black magic at first glance.

Read more…

Fear & loathing in functional testing land

As projects grow the two things I’ve repeatedly found to be particularly painful have been functional testing and data fixtures. I might write up some thoughts on data fixtures another time but what follows is a brain-dump of my troubled relationship with functional testing.

Disclaimers: I have more questions than answers and I’m completely open to the idea that I’m doing it all wrong. I’m not trying to diss any tool or technique here. I have spent a lot of time over the last few years writing functional test coverage so I think I at least have some perspective on the issues if no clue how to solve them.

Read more…

Grails Gotcha: Beware HEAD requests when rendering binary output in controllers

Although most Grails controllers render HTML, JSON or XML output it is possible to use them to render binary data as well. We use a controller to render images uploaded by editors into our content management interface. The theory is simple enough, instead of using the render dynamic method or returning a model the controller action just writes bytes directly to the HTTP response stream. Our action looked something like this:

def show = {
    def image = Image.read(params.id)
    if (image) {
        response.contentType = image.contentType
        response.outputStream.withStream { stream ->
            stream << image.bytes
        }
    } else {
        response.sendError SC_NOT_FOUND
    }
}

This seemed to work well enough. However when writing a test I noticed an odd thing. I was using RESTClient to scrape resource URLs out of and make a HEAD request against them to ensure the URLs were valid. Javascript and CSS files were working fine but all the non-static images in the page were getting 404s.

Read more…

Web Statistics