Many people ask me about this comparison and even about the proportion of each type of tests.

I faced several situations when I needed to evaluation the best approach and of course is not like black and white situation, but I personally defend that should always favor the Unit Tests.

I compiled a comparison table about the two types of tests to help us to brainstorming about it.

Integration Tests VS Unit Tests

Integration TestUnit Test
Difficult to maintainEasy to maintain
Usually don´t test every possible pathUsually test every method parameters combinations and paths
Difficult troubleshooting (many objects, many layers, many external resources are involved)Straightforward to identity the problem and to fix (test of single unit of code)
Can take long time to executeIs fast to execute
Parallel execution could causes problemsAre executed in parallel with no problems (if well done)
Can be executed against any kind of implementationForce us to improve the code to make it testable.
Complex to setupEasy to setup
Can give false-positive result (since it’s a black box test we can get correct result without knowing exactly how this result was generated – could be fixed or manipulated data i.e)We are testing a small piece of code and we can perform multiple types of validation not only against the result but how it’s generated

So why/when we need Integration Tests

Have more and good unit tests will ensure more product quality

So why we need and why we have Integration Tests

The integration test provide us a test of integration parts like:

  • contracts
  • connections (databases, caching system, message queue…)
  • application bootstrap
  • infrastructure aspects (protocols, access control, authentication…)

How many integration tests we need to test this “integrations”?

Just a few tests. Not for all functionalities or use cases.

That’s why we should have much more unit tests (good tests with high code coverage)