Versions Compared

Old Version 2

changes.mady.by.user Steve Conrad

Saved on

compared with

New Version Current

changes.mady.by.user Benjamin Balder Bach

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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

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

...