Integration tests/unit tests: Doing too many integration tests?

Question

I have been designing a number of unit tests that mock out each dependency that each Unit Has. This works as expected. I now need to do integration tests.

So for example, I have 1 layer that depends on 2 additional layers, I have tested each individual layer separately as a unit mocking each dependency out but I now need to perform integration tests.

So imagine I have the following three layers..

  Layer1 > Layer2 > Layer3

I can do an integration test on Layer1 which would has real instances (rather than mocks) for Layer2 and Layer3.

So should I do an integration test for Layer2? which include the following workflow

  Layer2 > Layer3

Again nothing is mocked out here, they are integration tests.

The problem I am seeing is that my integration test from Layer1 really covers the same integration test for Layer2.

I am not too sure if I am taking this a little too far. I know its better to have more tests rather than not enough but I am seeing duplicates when testing layer1

  Layer1 > Layer2 > Layer3

and layer2

  Layer2 > Layer3

So I could probably just test Layer1 - using integration tests

  Layer1 > Layer2 > Layer3

which would probably cover layer2 and layer3 integration tests

  Layer2 > Layer3 

Answer 1

You should test whatever scenario is achievable in your application (via customer/components interactions). If Layer2 can interact with Layer3 without Layer1 interference - test for it.

Think of integration testing as of testing of entire use case. Is there a situation where your customer can start by invoking Layer2 alone? If there is, test it. If not, why would you do that? Never test something that is not used. This is the same as writing code that "someone might need later". It's waste of time, don't do that.

Answer 2

Integration tests are sometimes useful but they come at a high cost in terms of performance and complexity.

IMO they shouldn't be used for exhaustive verification of a system's behavior, the number of moving parts they include and the number of combinations of their behaviors is generally simply too high.

I mainly do integration tests for 2 purposes :

• At the beginning of a project, end-to-end tests are the first tests you should write if you want to set up a Walking Skeleton which represents a simple fully functional first little slice of your system.

• Testing the integration between your system and third party code. Or, more precisely, testing that the adapters you wrote to isolate your system from third party modules do call these third party modules correctly.

The book "Growing Object-Oriented Software, Guided by Tests" contains very helpful guidelines if you're struggling to get your head around all the different testing practices and when to use them.

Answer 3

I tend to define integration test loosely. If I see a test that covers the interaction between several classes, I tend to call it an integration test (there's another term for this, but I can't recall it right now). To me, it's not just about layer integration.

The idea is that you should do integration tests based on key scenarios and/or important use cases. From those things, you'll know where your integration tests should start from. Don't create integration tests for the sake of creating it. They tend to be too much work and maintenance when used for less important bits.

In your example, if you have an integration test on Layer1 which hits all three layers, then that covers your scenario adequately. As mentioned in an earlier answer, there's no need to purposely test Layer2 > Layer3 unless you're saying that something else may hit Layer2 and bypass Layer1 completely. But even if that were the case, I'd prepare an integration test starting from that "something else". Only test Layer2 > Layer3 when you have a use case that starts from Layer2.