views:

183

answers:

3

I'm connecting to a simple, if idiosyncractic, external service.

I believe that my unit tests should not depend on the availability or implementation of that external service, so I intend to mock it out.

I need the mock to accept and return realistic messages and responses - otherwise my tests won't represent real states of affairs. For example, it has to throw the right kind of errors - and there are at least 7 different ways it can fail (between you and me it's not a very well designed external service). Therefore, at a bare minimum I have to have a hash of message/response pairs.

So instead of reducing contingency, mocking has reintroduced it somewhere else. In fact, as the saying goes, now I've got two problems: I've got to be sure that what's in my hash is a fair representation of how the external service behaves. But surely the canonical source of what response object X gives to message m is X itself. Anything else is risky and messy.

Have I taken a wrong turn? How can I eliminate this apparent circularity?

EDIT I've clarified what I think the problem is in the light of Justice's helpful comments.

A: 

Your mock intended for unit tests should not accurately represent the external service. You should pick pre-defined sets of input and output values for the mocked external service. They may or may not be what the external service would actually return (but they should be "kind of" real). The objective of your unit tests is to double-check that your objects behave correctly, given this set of inputs and outputs, for a certain meaning of "correctly."

Justice
Thanks - I've edited the qu in the light of your clarifying comments. I'm not sure you answered my underlying concern. If you've got a moment, can you take another look? Cheers.
Dave Nolan
A: 

Make sure that anything your class depends on has an interface (as opposed to just a concrete implementation), and then you can use JMock. This will simplify your testing immensely. You can do things like tell it to expect a method call X, return a particular value, or throw an exception. It's really a timesaver.

Limbic System
+1  A: 

Let me refer you to my two answers at another question about unit testing just to avoid repeating myself, first.

The thing I think that mocking gives you in this environment is that it's rigorously specifying what you think the behavior of that external interface is going to be. This means that you've got a controlled test (something tells me this external service changes every so often.) So, not only can you test and debug your code with a known "good" sequence of responses, but you have a documented set of examples of what you expect.

If I were in that situation, and depending on the real service, I'd be tempted to write a unit test or mock for the external service as well. That way, if you observe a fault in real operation, you can (1) run the test against your code using the mock for the external interface, and (2) test the external service against your expectations.

The point, though, i to have something for which you have real confidence and which you completely control.

Charlie Martin
Ah yes, that's it, thanks. Risk and maintenance ain't going away, by simple virtue of the fact it's an _external_ service! But by expressing my expectations of its behaviour, I isolate the uncertainty.
Dave Nolan