Are integration tests for only the topmost level of a hierarchy of object compositions? Or for each level except the bottom?

Question

Suppose we have a hierarchy like the following, where each thing under it means it is composed of that type:

CarCompany
    |
CarFactory
    |
   Car
    |
  Engine
    |
    +------+-----+
    |      |     |
   PartA PartB PartC

For everything above, also assume each component has logic associated with it and it's not just a glorified collection. As such, a CarCompany owns many CaryFactorys, which in turn makes multiple Cars, which have their own possible Engine types, and those are made up of atomic Parts.

Now suppose that we have interfaces used for each step, like:

• CarCompany adds new factories with a CarFactory interfaces
• CarFactory adds cars by a Car interface
• A Car adds its engine by an Engine interface

As such, this makes unit testing easier since we can mock the interfaces and make sure the logic works without spending forever instantiating stuff.

When it comes to integration testing however, we want to make sure everything works as intended... but at what level do we do integration testing? Do we do a bunch of integration tests at the top level? Or do we do one for each level that accepts an interface?

Reason I'm asking is because integration testing is suppose to make sure our classes integrate together by definition, which means wherever we have an interface we want to test with concrete instances. However this implies that we would do testing at N - 1 levels for N levels, since the bottom level does not need to be tested. Is this overkill though? Or should integration testing only be done at the top level?

Answer 1

Reason I'm asking is because integration testing is suppose to make sure our classes integrate together by definition

This is wrong.

Classes existed long before the idea of integration testing. Integration testing is simply testing without requiring isolated units. If you can isolate your units you have unit testing. A unit is a cohesive group of local code. Code that can work together fast. Integration tests are tests free of those restrictions. That makes them slow. But this still has nothing to do with classes.

Classes get confused with units and modules all the time. These are very different ideas. A unit might be one class or many classes or no classes at all. A unit is an imaginary box that does things when you do things to it. It's an idea that can be understood in that manner. That's what makes it testable.

When you are integration testing you are not testing the units. You are testing how you put the units together. If a unit is faulty the unit test should fail. An integration test is not under an obligation to fail in this case. It might and it might not. The integration test must fail if the connections between the units are faulty.

Integration tests are often confused with end to end tests that go through an entire use case. That's not what they are either. Integration tests are only about how things are connected. Which means I could integration test the cars electrical system, in place, without ever turning the engine over, using a voltmeter.