This Blog Has Moved!

Right, so yes, five years ago I moved to github pages, and never bothered to redirect any of these pages there. Now I've moved on from there, and... Finally I am using my real domain, trishagee.com . My blog is now at trishagee.com/blog .  See you there!

Spock passes the next test - Painless Stubbing

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.

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 bsonWriter.

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 (video doesn't seem to work but slides can be seen) 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 org.mongodb.MongoException whenever 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 rename.

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:

Ick.

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:

Comments

  1. I believe it's really cool that you can give suggestive names to the test methods (BDDish), without camel case or underscore overhead. With java/junit I've been using the pattern test{methodUnderTest}_{inputConditions}_{expectedBehaviour} but it's definitely easier to read the methods using Groovy style.

    ReplyDelete
    Replies
    1. Yeah - I find it particularly useful in the above case because I want to give the fully qualified package names to make it clear what's expected.

      Delete
    2. Would be cool to have support in IDEs to warn you about the test method name if you were to move com.mongodb.MongoException to a different package or rename the exception. Oh well ... :) thanks for the post.

      Delete
    3. IntelliJ will also do text replacements when you do a rename, if you want it to.

      Delete
  2. @Trisha,

    Nice article.. But the link you provided seems to be broken.

    ReplyDelete
    Replies
    1. Thanks, fixed - looks like the content might not be fully available though.

      Delete

Post a Comment

Comments have been disabled since this blog is no longer active.

Popular posts from this blog

Dissecting the Disruptor: What's so special about a ring buffer?

Dissecting the Disruptor: Writing to the ring buffer

Dissecting the Disruptor: Why it's so fast (part one) - Locks Are Bad