So this is something I run into quite often, and in my experience, the classes which just delegate to other services aren’t really worth testing that well. At best, test that it passes down the right parameters, and assume that the service you are delegating to is well tested and does what it should. If that service is one of your own, test that thoroughly instead. And most of all, have some integration tests which test the entire thing.

Like if you are delegating to something that talks to a database, maybe have a test which has an actual (or fake db) at the back, and tests that this delegates properly and returns the right thing. But on the unit test level, have maybe one test per delegation, and leave it at that.

Hope that helps.

I’ve been getting in to unit testing these past months and have been browsing around for any tips, best practices and so on I can read. I found this post today and in the disadvantages about Mocks you mentioned something that has been bothering me these past few days. I feel that some of the tests I wrote with mocks are mostly testing the interaction between the mocks and depend too much on the implementation! Do you have any advice on how can this be avoided? Some methods are just delegating to other collaborators and I’m not sure how to test them properly.

Thanks in advance.

I see what you mean about the possible work involved in configuring a fake DB, as opposed to mocking it. Guess a lot depends on the nature of what’s being faked, as well as what facilities the fake provides and how well it’s been done.

Absolutely agree about using whatever’s best for each situation. I see far too much clutching at names and silver bullets these days, rather than thinking about what precisely is needed in each specific situation. Probably guilty of that myself at times, but do try to avoid it.

Fakes can (can, and not necessarily must) be hard to setup to work similar to an existing service. Also, to test the interesting cases with a Fake, you might need to get the, say FakeDB, into a particular state before you can do your actual test. These might be like adding specific rows, and getting the DB to a particular state. Whereas with a mock, you can just tell it to expect a call and return whatever you need it to. (Stubs of course, can never do this…). Also might be tough to use a Fake Http service and stuff (not impossible, but harder than it needs to be).

In the end, I feel it comes down to using what is most ideal for the situation. Use Fakes whenever you can, and whenever time and complexity permits, but use Mocks to get things going quickly and if you want to test edge cases easily and use stubs if you need to just get through the offending material.

My own take on “fakes” is that it can indeed be a lot of work to create really good fakes (including testing them, as you point out). But for widely used API or services I think it can make sense for someone to do this centrally, and produce a library of “ideal” fakes for that API. Everyone else can then just use the pre-written, pre-tested fakes.

Ideally I’d like to see this as a responsibility of API design and implementation. If an API actually needs test-doubles or a fake service in order to be easily testable, the API ought to supply this. And this ought to be taken into account in the API design (e.g. avoid needing it if possible, or make it as straightforward as possible). Well, we can all dream…

In terms of speed, if a fake is just doing normal in-memory stuff, it might involve slightly more than a mock but this shouldn’t normally be so much as to impact performance. You can churn through an awful lot of “plain” code before noticing any impact, and the code that you’re testing probably does as much or more than the fake. At least that’s been my experience.

I’d say defining expectations is different for a fake, rather than harder, with a lot depending on the precise nature of the fake. If the fake lets you configure and inspect everything relevant to the object’s behaviour, and can record the API calls too, then you’ve got eveything you need. I don’t think there has to be anything making it intrinsically harder than strictly necessary.

So on the whole I tend to regard “fakes” as the ideal – if you can get someone to develop them for you!

At any rate, that’s my personal view on fakes, based on writing a set for the Servlet API.

Mike