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
The Consent BB can function as a POC
Whenever needed, the Sandbox team should have access to BB repositories so they can develop and maintain their own solutions in
examples/.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 withtest_entrypoint.shNaming 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/mockmight be too generic for a long-term. Other names could beexamples/mock-staticorexamples/mock-simple+examples/mock-usecase-usctetc.
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.