1

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?

  • 3
    You would choose your tests in the manner which best expresses a sound testing strategy for your particular application. – Robert Harvey Dec 27 '19 at 20:48
  • 1
    @RobertHarvey Sort of tough to pick a sound testing strategy when the question is about how to pick a sound testing strategy. Maybe instead you should say under what conditions you'd do one and under what conditions you'd do the other method so people like myself can get some insight into this. – Water Dec 28 '19 at 0:37
  • @Water: one does not pick am integration testing strategy just by looking at a class hierarchy. One develops a strategy in the whole context (is this a learning example, a game, a web-shop, a word-processor, is this a 2 weeks project of a student, or a 40 person years project., what are the quality requirements, which issues are observed during development?). IMHO the only answer I could give you here is start testing on a real project, look where integration testing makes most sense for that real application and learn from it. – Doc Brown Dec 28 '19 at 5:18
  • @DocBrown Any recommended projects that do it right? I have been unable to find one as if I had one then my question probably would be answered, and integration testing wasn't even a thing in any of my dev jobs so I have no experience to go off of either. – Water Dec 28 '19 at 5:27
  • @Water: sqlite.org/testing.html - they don't use the word "integration tests" there, but lots of the tests they mention there fall into that category. – Doc Brown Dec 28 '19 at 7:31
3

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.