Summary
Evaluate candidate frameworks for building a self-contained integration test suite for registry-loader. The approach should use an HTTP-level mock (e.g. WireMock, MockServer) to intercept OpenSearch REST calls — rather than testcontainers with a clean OpenSearch instance — because real-world production issues often involve quirks of specific OpenSearch deployments (throttling, OCU limits, partial bulk failures, 409 conflicts) that a clean instance would not reproduce.
Additionally, evaluate Cucumber as the BDD test framework to align with other PDS software repositories that use it.
Acceptance Criteria
- A written recommendation (ADR or design note in the repo) comparing at least two HTTP mock frameworks (e.g. WireMock vs MockServer) against registry-loader's specific needs
- Cucumber evaluated for fit as the BDD layer on top of the chosen mock framework
- Recommendation includes: ease of simulating partial bulk API failures and error responses, CI footprint (no Docker required), compatibility with the existing Maven build
- Decision is documented and linked to the parent theme
For Internal Dev Team To Complete
⚙️ Engineering Details
🎉 Integration & Test
🤖 Generated with Claude Code
Summary
Evaluate candidate frameworks for building a self-contained integration test suite for registry-loader. The approach should use an HTTP-level mock (e.g. WireMock, MockServer) to intercept OpenSearch REST calls — rather than testcontainers with a clean OpenSearch instance — because real-world production issues often involve quirks of specific OpenSearch deployments (throttling, OCU limits, partial bulk failures, 409 conflicts) that a clean instance would not reproduce.
Additionally, evaluate Cucumber as the BDD test framework to align with other PDS software repositories that use it.
Acceptance Criteria
For Internal Dev Team To Complete
⚙️ Engineering Details
🎉 Integration & Test