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!
Post a Comment

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. Unknown10 July 2013 at 09:20

    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. Trisha10 July 2013 at 09:45

      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. Unknown10 July 2013 at 09:56

      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. Trisha10 July 2013 at 21:39

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

      Delete
  2. Suresh S Murthy17 November 2015 at 01:18

    @Trisha,

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

    ReplyDelete
    Replies
    1. Trisha17 November 2015 at 08:57

      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?

Image
Recently we open sourced the LMAX Disruptor , the key to what makes our exchange so fast.  Why did we open source it?  Well, we've realised that conventional wisdom around high performance programming is... a bit wrong. We've come up with a better, faster way to share data between threads, and it would be selfish not to share it with the world.  Plus it makes us look dead clever. On the site you can download a technical article explaining what the Disruptor is and why it's so clever and fast.  I even get a writing credit on it, which is gratifying when all I really did is insert commas and re-phrase sentences I didn't understand. However I find the whole thing a bit much to digest all at once, so I'm going to explain it in smaller pieces, as suits my  NADD audience. First up - the ring buffer.  Initially I was under the impression the Disruptor was just the ring buffer.  But I've come to realise that while this data structure is at the hea...
Read more

Dissecting the Disruptor: Writing to the ring buffer

Image
This is the missing piece in the end-to-end view of the Disruptor.  Brace yourselves, it's quite long.  But I decided to keep it in a single blog so you could have the context in one place. The important areas are: not wrapping the ring; informing the consumers; batching for producers; and how multiple producers work. ProducerBarriers The Disruptor code has interfaces and helper classes for the Consumer s, but there's no interface for your producer, the thing that writes to the ring buffer.  That's because nothing else needs to access your producer, only you need to know about it.  However, like the consuming side, a ProducerBarrier is created by the ring buffer and your producer will use this to write to it. Writing to the ring buffer involves a two-phase commit.  First, your producer has to claim the next slot on the buffer.  Then, when the producer has finished writing to the slot, it will call commit on the ProducerBarrier . So let's look at...
Read more

Dissecting the Disruptor: How do I read from the ring buffer?

Image
The next in the series of understanding the Disruptor pattern developed at LMAX . After the last post we all understand ring buffers and how awesome they are.  Unfortunately for you, I have not said anything about how to actually populate them or read from them when you're using the Disruptor. ConsumerBarriers and Consumers I'm going to approach this slightly backwards, because it's probably easier to understand in the long run.  Assuming that some magic has populated it: how do you read something from the ring buffer? (OK, I'm starting to regret using Paint/ Gimp .  Although it's an excellent excuse to purchase a graphics tablet if I do continue down this road.  Also UML gurus are probably cursing my name right now.) Your Consumer is the thread that wants to get something off the buffer.  It has access to a ConsumerBarrier , which is created by the RingBuffer and interacts with it on behalf of the Consumer .  While the ring buffer obviously n...
Read more