Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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 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.

  • No labels