What is integration-test?
An integration test checks how different parts of a software system work together. Instead of testing a single function in isolation (unit test), it combines multiple components-like modules, services, or databases-to see if they interact correctly and produce the expected results.
Let's break it down
- Unit: Test one tiny piece of code alone.
- Integration: Take two or more pieces and run them together.
- Goal: Find problems that appear only when components talk to each other, such as mismatched data formats, wrong API calls, or configuration issues.
- Typical steps: set up the needed pieces (e.g., start a test database), run a scenario that uses them, then verify the outcome.
Why does it matter?
If you only run unit tests, you might miss bugs that happen at the boundaries between parts. Integration tests catch those hidden issues early, reducing costly fixes later, improving overall system reliability, and giving confidence that the whole application works as intended.
Where is it used?
- Web applications that connect front‑end UI, back‑end services, and a database.
- Mobile apps that rely on external APIs.
- Micro‑service architectures where many small services must communicate.
- Any system where separate modules need to exchange data or trigger actions in each other.
Good things about it
- Detects real‑world bugs that unit tests can’t see.
- Validates that configurations, network calls, and data flows are correct.
- Provides a safety net when refactoring or adding new features.
- Helps teams trust that the assembled product works, not just its parts.
Not-so-good things
- Slower to run than unit tests because they involve more components.
- Can be harder to set up and maintain (need test databases, mock services, etc.).
- Failures may be less specific, making it tougher to pinpoint the exact cause.
- If not well‑scoped, they can become large “end‑to‑end” tests that blur the line with UI testing, reducing their usefulness.