Dropwizard integration tests: choosing an external-service mocking strategy that guarantees no production credential leakage

Context

DropwizardAppRule starts the full application lifecycle for integration tests, loading a test-specific YAML configuration that can override production values through environment variables or system properties. The framework does not prescribe a single approach for mocking external HTTP services, databases, or message brokers, leaving teams to decide between WireMock stubs, Testcontainers-backed real dependencies, or in-memory implementations.

Constraint

Health checks, managed objects, and database migrations execute during rule startup, so any external dependency that is not fully mocked or redirected will cause startup failures or, worse, accidental calls to production endpoints if a configuration override is missed. Static configuration singletons cached from earlier test runs can also leak production values into subsequent tests.

Goal

Establish a repeatable pattern that ensures every production credential reference is replaced in the test configuration and that the chosen mocking strategy works reliably in both isolated and parallel test execution.

Which mocking strategy—WireMock, Testcontainers, or in-memory fakes—provides the strongest guarantee that no production credentials are exercised during DropwizardAppRule-based integration tests? How can a test suite automatically verify that all credential-bearing configuration keys have been overridden before the application starts? What lifecycle hooks or JUnit extensions are recommended to reset static configuration state between parallel test classes?