Is integration testing an umbrella term and if so, what types of tests does it include?

I find the concept of 'integration testing' confusing. There seems to be quite a few explanations and scopes:

• Functional/acceptance testing (e.g. testing the user interface with for example, Selenium)
• Testing the integration of different classes/modules of software together (simply testing two or more classes together, without them doing anything special like db calls and stuff)
• Testing the system configuration function/feature-independently (database integration works, dependencies are correctly injected, security base classes work)
• Testing the system as whole (running services that use databases, web services, etc.)
• etc. etc.

I begin to see integration testing as an umbrella term (as opposed to defining it in programming talks, where specific/strict meaning is often given to it):

• Integration testing contains:
  • Unit integration testing (test integration of different classes within the same package without calling external libraries)
  • Functional/acceptance testing (test final output of the software through Selenium, for example)
  • System testing (includes various, more technical & non-feature related tests as listed in Wikipedia article)

In Maven default lifecycle, there is only 'test' and 'integration-test' phases. This seems to split the tests into roughly two categories and would go along with these assumptions.

There are many exist开发者_JAVA百科ing questions and answers looking for differences between unit testing, functional testing, regression testing, etc. in general. However, I am looking for more specific answer regarding integration tests: how do you categorize integration testing and what do you include inside it? Also, do you shun splitting software testing roughly into two categories as I have done: unit tests (1 unit) vs. integration tests (2+ units)?

Computing is full of overloaded terms that have a slightly (and sometimes not so slight) different meaning to any programmer you talk to. Integration testing is one of those.

I tend to favour your interpretation of integration testing as testing 2 or more units plugged together. But this is still rather fuzzy as we may have different definitions of what a 'unit' is.

I think it's more important that a team of developers agree on what they mean by integration testing rather than finding the one true definition of integration testing.

My team sees (using your words), integration testing as covering

• Testing the integration of different classes/modules of software together (simply testing two or more classes together, without them doing anything special like db calls and stuff)
• Testing the system configuration function/feature-independently (database integration works, dependencies are correctly injected, security base classes work)

and nothing else. System tests and acceptance tests we see as different families.

we had some lengthy discussions on this, to make sure that we were all speaking the same language when we talked about tests.

I'm not strongly disagreeing with what you define as integration tests, but I'm just saying that it's nice if all the people you're working with agree on a classification.

Well, you have unit testing, the precise definition of which varies, but certainly contain all those tests defined with a JUnit-like tool and organised in the same way as the source code. If for any source code file, you can find one and only one test, then the thing you found is a unit test.

And then there is system testing, which tests the complete system in as close as possible a way to a customer will see it.

Any testing that lives in the gap between those two things is an integration test - neither isomorphic with the source code nor representative of an end user experience.

That's a pretty big gap between two categories that themselves vary a lot in practise. That gap can contain a lot of potentially useful tests, but the nature of those tests will naturally vary pretty dramatically.