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 ‘testing’

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…

Fixing current time for tests with Java 8's date/time API

For years I’ve used the Joda Time library to provide a nicer alternative to the horrible mutable java.util.Date class and the terrifying abyss of java.util.Calendar. One thing, as a fanatical tester, that really appealed to me was the existence of the DateTimeUtils class. All the Joda Time types use DateTimeUtils as a source of the current instant and it exposes methods that allow tests to fix or offset the value that’s returned. That can rule out some irritating flakiness in tests and enable testing of time zone / daylight savings bugs, timeout logic and so on while retaining the encapsulation of timestamp generation in production code.

Of course, when you look at DateTimeUtils with purist eyes it’s a horrible hack. A static singleton encapsulating global mutable state! I guess that was the attitude of those responsible for JSR-352 that created the new java.time package which is largely based on Joda Time. One of the things that wasn’t carried over from Joda Time is the DateTimeUtils class. Instead factory methods such as Instant.now() use a Clock object – by default Clock.systemUTC().

Read more…

How can test it if I don't know what I'm building yet?

One objection to the practice of TDD I’ve heard from several different people is along the lines of “I don’t know exactly what I’m building at the outset, the code is experimental, so how can I write tests for it?”

Frequently it is the case that you have an idea but don’t know the mechanics of how you’re going to implement it. I find this particularly when I’m writing code that extends a third-party library. You don’t know exactly where the API hooks you’ll need to use are, your understanding of the API is fuzzy and you expect to learn it as you go. So how do you test-drive in that situation?

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…

Unit testing Angular directives that use controller and templateUrl

I spent an hour or so this morning figuring out how to unit test an Angular directive that uses a controller and a template loaded from a file (as opposed to inline). There’s a useful example in the ng-directive-testing repository but I thought a quick summary would be useful (as much to remind me the next time I have to do it as anything). Also the examples there test by interacting with DOM elements rather than directly with the directive’s scope.

Read more…


Mongo dynamic attributes and Grails unit tests

When using Mongo DB with GORM it’s possible to assign to dynamic attributes of a domain class. However, you’ll find that when you write unit tests for code that uses this feature it isn’t supported. It’s easy to emulate, though.

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…

Getting started with Angular unit tests

I’ve been pretty enthusiastic about Angular for a while now but although I was encouraged by the consideration given to testing hadn’t really tried unit testing my Angular components. I’ve been using Casper to test end-to-end which has been good enough for the experimental stuff I’d been doing with Angular. When I recently started working on a real app with a fairly complex Angular controller it felt like I needed to define the logic with some fine-grained unit tests.

Read more…

Web Statistics