Mocking for integration tests

问题:

How does one mock the many dependencies needed for integration tests?

I use Mockito for my 'pure' unit tests. 'Pure' in this case means testing a single class, mocking all of it's dependencies. Beautiful.

Now come integration tests. Let's say in this case an integration test will test something like this:

1. Message is put on a queue
2. Message is 'processed'
3. Response message is put on a response queue

Let's also say that the processing that happens in step 2 is serious stuff. It relies on lots of database interactions, on multiple external services, the file system, all kinds of things. There are also a lot of side effects that the flow will trigger, so I cannot simply ensure that the response is correct - I need to verify the side effects.

Each of these dependencies are wrapped by a single stateless service class, which makes them nice and mockable.

How are folks handling this?

I would love to use Mockito so that I could verify the side effects that the above flow will have. However, Mocktio's documentation (and to a large extent it's implementation) seems to fight strongly against using it in contexts other than 'pure' unit tests. I've tried to go this route, but

• It's difficult to populate the stub data (as there's lots of it)
• It's difficult to have Spring inject those stubbed instances into my beans
• It's difficult to 'reset' the mocks so that I can verify a different set of interactions without clearing out the stubs.

EDIT

I know that I could handle the database issue with something like an HSQLDB instance, but there's still the issue of the external services. For repeatability I can't rely on those services being up, being in the state that I require, etc. The only option I see there is to mock them.

Whatdaya do?

回答1:

Great question.

It seems like you hit the limits of Mockito. Mockito is great if what you want to inspect object interactions.

What you want, though, seems to be observability (and controllability) at a higher level of abstraction. I'm afraid that the mocks or stubs you need for that should be carefully designed and hand-crafted.

At the unit level, these mocks can be nicely generated, by means of Mockito. At the integration level, this becomes much harder, and you will need purpose made testability interfaces.

回答2:

In order to mock things like databases, web services, the file system and so on, you will probably want to refactor a little. For each external service, you should write a wrapper class that has a method for each operation that you wish to perform. Each such method should have no actual logic, but just pass through its parameters in the way that the external service will understand, and return an object that contains whatever data the external service returns. For example, if you're interacting with a database, the wrapper class might format its parameters into an SQL statement, submit them into an existing Connection object, and return a List for the result.

Because the methods of the wrapper class contain no logic (that is, no if/else, no loops and no exception handling); there is no need to unit test the wrapper class. You should integration test the wrapper class, to make sure that its responsibilities are performed correctly (that is, that the SQL statement has the desired effect on the database, for example).

Now re-write the classes that interact with the external services so that they interact with the wrapper classes instead. It's then easy to unit test them - you just have to mock the wrapper classes.

回答3:

If there is some http or rest mock framework, using that should be good.

All the complicated dependencies can be recorded, modified and replayed.