When it comes to out-of-process dependencies and mocking, the guideline is the following:

Use real instances of managed dependencies; replace unmanaged dependencies with mocks.

In other words, you shouldn’t mock your database, but you should mock the message bus.

Here’s a question I received on this topic:

I’ll tackle the second question first because it’s easier.

Yes, such a message bus is still an unmanaged dependency because in production, it’s still accessible by other applications. We don’t count the dependency’s clients during testing, we count them during the use in production.

It doesn’t matter if you run the out-of-process dependency in a Docker container or not. Containers don’t change the dependency’s categorization.

Now, let’s talk about the mocking aspect. Since you can isolate an instance of the message bus for testing, should you really mock that message bus? Wouldn’t it be better to use a real instance of it?

Let’s take apart this question. First of all, it doesn’t really matter whether you use Docker or not. You can have a separate instance of an out-of-process dependency for testing without Docker containers. Granted, it’s usually easier to do so with Docker, but there’s nothing inherently preventing you from running a test message bus elsewhere.

There’s something to be said about using containers for each test run, not just as one shared message bus instance. It might seem compelling because it would allow you to parallelize your tests.

In practice, though, this approach creates too much of an additional maintenance burden. With Docker, you need to:

If you decide to use a real message bus in tests, it’s more practical to have just one its instance per developer.

Now, what about mocking? Do you always have to mock all unmanaged dependencies? Or can you use their real instances like you do for managed dependencies such as the database?

No, you don’t have to always mock unmanaged dependencies. Let me refine the mocking guideline above:

You should always use real instances of managed dependencies in tests. You can (but don’t have to) replace unmanaged dependencies with mocks.

This guideline is meant to discourage the use of mocks for the database and other managed dependencies, because it leads to brittle tests. However, you don’t have to mock unmanaged dependencies. From a test brittleness perspective, it’s perfectly fine not to mock them if you can.

Alright, so you don’t have to mock the message bus. But should you? Which option is better?

To answer this question, we need to resort to our framework with the 4 components of a good test, which I described in the Unit Testing book. Here are those components:

Let’s look at our options (mocking and not mocking the message bus) using the above 4 components. We’ll start with the 2nd one.

So the choice between mocking vs not mocking the message bus boils down to the choice between better protection against bugs vs worse maintainability.

I would say the additional burden of maintaining a test message bus isn’t worth the additional gains in protection against bugs.

You only need to test the end-to-end integration with the message bus once. After that, you only need to check what messages your application generates for that bus.

And you can do that initial end-to-end testing manually. There’s no need to come up with additional test infrastructure and take on additional maintenance burden for a task that can be resolved within a couple hours of manual labor.

Not everything should be automated away. Consider the long-term costs of both approaches.