In the last post I talked about our need for some improved testing tools, our choice of Spock as something to spike, and how mocking looks in Spock.
As that blog got rather long, I saved the next installment for a separate post.
Today I want to look at stubbing.
Mocking is great for checking outputs - in the example in the last post, we’re checking that the process of encoding an array calls the right things on the way out, if you like - that the right stuff gets poked onto the
Stubbing is great for faking your inputs (I don’t know why this difference never occurred to me before, but Colin’s talk at Devoxx UK made this really clear to me).
One of the things we need to do in the compatibility layer of the new driver is to wrap all the new style Exceptions that can be thrown by the new architecture layer and turn them into old-style Exceptions, for backwards compatibility purposes. Sometimes testing the exceptional cases is… challenging. So I opted to do this with Spock.
So here we can use a real
DB class, but with a mock
Mongo that will return us a “mock”
Session. It’s not actually a mock though, it’s more of a stub because we want to tell it how to behave when it’s called - in this test, we want to force it to throw an
execute is called. It doesn’t matter to us what get passed in to the execute method (that’s what the underscore means on line 16), what matters is that when it gets called it throws the correct type of Exception.
Like before, the
when: section shows the bit we’re actually trying to test. In this case, we want to call
Then finally the
then: section asserts that we received the correct sort of Exception. It’s not enormously clear, although I’ve kept the full namespace in to try and clarify, but the aim is that any
org.mongodb.MongoException that gets thrown by the new architecture gets turned into the appropriate
com.mongodb.MongoException. We’re sort of “lucky” because the old code is in the wrong package structure, and in the new architecture we’ve got a chance to fix this and put stuff into the right place.
Once I’d tracked down all the places Exceptions can escape and started writing these sorts of tests to exercise those code paths, not only did I feel more secure that we wouldn’t break backwards compatibility by leaking the wrong Exceptions, but we also found our test coverage went up - and more importantly, in the unhappy paths, which are often harder to test.
I mentioned in the last post that we already did some simple stubbing to help us test the data driver. Why not just keep using that approach?
Well, these stubs end up looking like this:
And you end up extending them so you can just override the method you’re interested in (particularly in the case of forcing a method to throw an exception). Most irritatingly to me, these stubs live away from the actual tests, so you can’t easily see what the expected behaviour is. In the Spock test, the expected stubbed behaviour is defined on line 16, the call that will provoke it is on line 19 and the code that checks the expectation is on line 22. It’s all within even the smallest monitor’s window.
So stubbing in Spock is painless. Next: