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 Test | Unit Test |
---|---|
Difficult to maintain | Easy to maintain |
Usually don´t test every possible path | Usually 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 execute | Is fast to execute |
Parallel execution could causes problems | Are executed in parallel with no problems (if well done) |
Can be executed against any kind of implementation | Force us to improve the code to make it testable. |
Complex to setup | Easy 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)