Which strategy best prevents brittle tests when using interface-based mocks for external API integrations?

In Go, decoupling business logic from external dependencies is typically achieved by defining interfaces and injecting mock implementations during testing. While this allows for integration testing without production credentials, it introduces a risk where tests pass against a mock that no longer reflects the actual API contract.

Using net/http/httptest can simulate server responses, but maintaining synchronization between the mock's behavior and the evolving production endpoint remains a challenge. When running tests in parallel using the -parallel flag, avoiding global state for these mocks is critical to prevent race conditions.

What are the most effective patterns for ensuring that mock implementations remain aligned with production API specifications? Does the use of shared contract test suites between the mock and the real client provide a viable solution to prevent brittle tests?