Sandbox and Testing - Emulators and Mocks

There is a need for alignment with the creation of mocks and emulators between the needs of the Sandbox environment and the Testing team. @Benjamin Balder Bach has proposed the following solution:

Building Block alignment between sandbox and testing needs:

• High-level goal: Reuse solutions for sandbox deployments and future integration testing and vice versa

• Decision: All emulator/mocking solutions must live in BB repositories in examples/ folder and have the same structure for entrypoint and Docker Compose setup that is already in place.

  • Benefits: Aligns with BB release cycles, automated testing, avoids fragmentation between Sandbox team and individual BB WGs

  • Testing team facilitates that any necessary parameters for “test_entrypoint.sh” are added for Sandbox use cases

  • Whenever needed, the Sandbox team should have access to BB repositories so they can develop and maintain their own solutions in examples/.

  • The Consent BB can function as a POC

• Reminder: There are no imposed requirements on programming languages and frameworks for applications, adaptors, emulators, or mock setups in examples/. As long as it can be packed in a docker-compose setup and launched with test_entrypoint.sh

• Naming things is hard: We might need to solve some terminology challenges so it's clear what each mock or emulator is scoped out to do: examples/mock might be too generic for a long-term. Other names could be examples/mock-static or examples/mock-simple + examples/mock-usecase-usct etc.

Assumptions: I understood from Vasil that Sandbox could use the docker-compose to launch a sandboxed setup from examples/. But if there is a need for Kubernetes, I don't think it's a problem that it lives in examples/appName/ -- but perhaps it can maintain this Kubernetes elsewhere, pretty sure that's better.