Unit Testing vs Integration Testing
Unit tests verify individual functions in isolation; integration tests verify that components work together correctly. Both are necessary for a healthy test suite.
- 1.The Testing Pyramid
- 2.Unit Tests
- 3.Integration Tests
- 4.When Unit Tests Are Not Enough
- 5.Connection to Autonomous Code Governance
The Testing Pyramid
Unit tests and integration tests occupy different levels of the testing pyramid — a framework for thinking about test distribution. Unit tests form the broad base: many, fast, cheap to write. Integration tests occupy the middle: fewer, slower, more comprehensive. End-to-end tests cap the top: few, slow, expensive.
| Property | Unit Testing | Integration Testing |
|---|---|---|
| What it tests | A single function or class in isolation | Multiple components working together |
| Dependencies | Mocked / stubbed | Real (or realistic stubs) |
| Speed | Very fast (milliseconds) | Slower (seconds to minutes) |
| Isolation | Complete | Partial — tests component boundaries |
| What it catches | Logic errors in individual functions | Incorrect interactions between components |
| Count in a healthy project | Many (hundreds to thousands) | Moderate (dozens to hundreds) |
| Example | Test that validateEmail() rejects malformed input | Test that user signup creates a DB record and sends an email |
Unit Tests
A unit test verifies a single unit of code — a function, method, or class — in complete isolation from its dependencies. Dependencies (databases, APIs, file systems) are replaced with mocks or stubs. This isolation ensures that a test failure is caused by the unit under test, not by external factors.
Unit tests are the foundation of a healthy test suite: they are fast (run in milliseconds), cheap to write, and provide immediate feedback when logic changes break existing behavior.
Integration Tests
An integration test verifies that multiple components interact correctly — that the database layer correctly persists what the service layer sends, that the API correctly calls the downstream service, or that the authentication middleware correctly gates access.
Integration tests exercise code paths that unit tests cannot cover because they involve real component boundaries. They catch: incorrect interface assumptions, data format mismatches, and behavior that changes when real dependencies replace mocks.
When Unit Tests Are Not Enough
Unit tests can pass comprehensively while integration tests fail because the integration assumptions were wrong. Classic example: every unit is individually correct, but the service sends data in a format the database driver does not accept. Unit tests — which mock the database — pass. Integration tests catch the mismatch.
Connection to Autonomous Code Governance
Autonomous code governance generates both unit and integration tests as part of the fix verification process. When Hydra generates a fix for a security vulnerability, it writes unit tests that confirm the vulnerable pattern is resolved and integration tests where appropriate to verify end-to-end behavior. Both types are included in the pull request so reviewers can evaluate coverage quality alongside the fix itself.
Frequently Asked Questions
What is the test pyramid?
The test pyramid is a framework (popularized by Mike Cohn) that suggests test suites should have many fast unit tests, fewer integration tests, and very few end-to-end tests. The pyramid shape reflects the trade-off between test quantity, speed, and maintenance cost at each level.
What is a mock vs a stub?
A stub is a replacement for a dependency that returns pre-configured responses. A mock is a stub that also records interactions — you can assert that specific methods were called with specific arguments. Both are used in unit tests to isolate the unit under test from its dependencies.
What is an end-to-end test?
An end-to-end (E2E) test exercises the complete application stack from the user interface through all layers to the database. E2E tests verify that user-visible behavior works correctly. They are the slowest and most expensive test type — typically run on each deploy rather than every commit.
Stop flagging. Start fixing.
Hyrax reviews your pull requests, remediates issues autonomously, and closes the ticket.
Join the waitlist