Is integration testing just unit testing with fewer mocks?

...or am I oversimplifying?

And if I am oversimplifying, what really is integration testing, and why is it 开发者_如何学运维dramatically less a topic of conversation than unit testing*?

*Evidence - How often each tag is used on StackOverflow:

• Unit Testing - 8,595
• Integration Testing - 557

Unit testing is testing one component on its own - you are testing a "unit" (often a single class or a single method).

Integration testing is testing two components working together - you are seeing if they "integrate" well together.

Unit testing is performed by mocking the external components your one unit under test collaborates with.

In integration testing, you are testing using the real thing, not mocks. Hence integration tests are not always so easy to automate and may need some manual involvement.

You're... roughly right, but there's a lot of interpretation about this topic. Unit testing can be (relatively) cleanly defined as testing of components in isolation for explicit functionality; from what I've seen, integration testing gets defined as "pretty much everything else". That's not to say there's not a well-defined place for it; even with good interface design, compatible components have nice and clean integration functionality, and that integration functionality can and should be tested independent of individual unit tests. It's just that sometimes, tests begin to blur the line between unit and integration test. At the very least, you can usually look at a test, and say "can this be decomposed into something simpler", and if not, you can usually define it as a unit test; if you can't do that, however, those seem to usually get lumped as integration tests.

Integration testing is a generic term for testing multiple 'units'. These can be components, classes, regression or acceptance tests. This is probably why it is not as popular a term - because it can have several interpretations, whereas unit test is 'the smallest possible testable thing.'

With respect to mocks, you shouldn't need too many mocks if you are unit testing. If you are using many mocks this could be a 'test smell' indicating you are testing a class that is too highly coupled to other classes.

You can think of unit testing as something a developer does, to make sure that each small unit (a method, for example) of his code is working as expected. Integration testing is when you (or a QA tester) tests multiple units in an integrated, or somewhat more end-to-end fashion.

Integration testing probably reflects more on real world use cases than unit testing does.

Both "unit" and "integration" testing have specific meanings, which others have given here. And that's fine for discussion on StackOverflow...

Problem is that just about everyone else uses "unit testing" generically to encompass both. How often have you seen "unit testing" on a Gantt chart, or heard someone say, "and the developers will do their units tests..."? Neither case means only testing of individual classes in isolation. Or, I hope not!

Worse, if you respond, "oh, do you mean the developers will do their unit and integration testing?" then you'll be looked at funny, because integration testing is what QA people do, right?

Personally, I really don't make a strict distinction, since I see it as a continuum (is two real classes and some mocks still a "unit" test?). What I'm ultimately interested in is "testing done by a developer to demonstrate their code does what they think it should do." Then I try to use whatever term is used by others in whatever context.