As our microservice ecosystem grows, our build times are exploding because we have too many slow integration tests. I'm trying to find the right balance. Should we lean more into Consumer-Driven Contract (CDC) testing with Pact to replace some integration tests? How do you maintain high confidence in a deployment without running a full end-to-end environment for every single pull request?
3 answers
The "Testing Pyramid" is still relevant, but for microservices, the "Testing Honeycomb" often works better. This means focusing heavily on integrated tests (testing the service and its immediate dependencies like the DB via Testcontainers) rather than full E2E. We implemented Pact for contract testing between our frontend and backend teams. This allowed us to stop running the full UI-to-DB tests for every change, saving us about 20 minutes per build. Contract tests ensure that if the API producer changes a field, the consumer build fails immediately, catching breaking changes much earlier than a traditional integration test would.
Are you using Testcontainers for your integration tests, or are you still relying on a shared "Dev" database that everyone points to?
Don't ignore ArchUnit! It’s a great Java library for "Architecture tests" to ensure developers don't accidentally create circular dependencies between packages.
I love ArchUnit! We use it to enforce that our 'Controller' layer never talks directly to the 'Repository' layer, keeping our hexagonal architecture clean and testable.
Patrick, we switched to Testcontainers last year and never looked back. Shared databases are a recipe for flaky tests because of data collisions. With Testcontainers, each test gets a fresh, isolated PostgreSQL instance in a Docker container. It’s slightly slower than a mock, but the confidence it gives you—knowing your SQL queries actually work against a real engine—is worth every second. It’s also made our local development environment much more consistent with our CI/CD runner.