Dual Testing

Strategy for Go projects: integration tests verify the full chain works, unit tests verify error handling logic. Derived from real implementations across multiple Go microservices using Vertical Slice Architecture, Gin, pgx/pgxpool, MongoDB, and testcontainers-go.

Core Rule

Integration tests (testcontainers) and unit tests (mocks) have different responsibilities:

• Integration tests prove that the full chain works end-to-end: HTTP request → middleware → handler → repository → database → response. They use real infrastructure via testcontainers.
• Unit tests prove that the handler's error handling logic is correct: mapping domain errors to HTTP status codes, validating input, handling infrastructure failures gracefully. They use testify/mock.

Some natural overlap on boundary scenarios (400, 404) is acceptable because the two test types exercise different concerns — integration proves the chain, unit proves the mapping. The anti-pattern to avoid is duplicating happy paths in both layers.

Decision Table

Use this to decide where a test scenario belongs: