What is the approach of the Consent BB (10 min)

• Consent BB has an emulator or mock.

• It is in full use: https://github.com/GovStackWorkingGroup/bb-consent

• Automated changes: from specification to mock/emulator application.

• The setup is designed to make manual overrides possible, but we are using dynamic fixtures to avoid this as much as possible. Currently, we aren’t using manual overrides, except in a POC for a status API in “/api/status/”.

Mock and emulator alignment

It’s currently unclear and undefined what differences there are between mocks and BB emulators. Many BBs use “mock” to denote “static mocks” and therefore, the Sandbox team has opted to say “emulator”.

We need to identify the overlaps AND the differences.

• Requirements and objectives

• Technical requirements

• Responsibility for implementation and maintenance: There needs to be a defined workflow for Sandbox, Testing, BB WGs and architecture team in order to build these cross-cutting solutions.

Requirements and objectives: Sandbox and testing team can develop the same solution, combining individual objectives.

Technical requirements: For instance, a BB example mock uses docker-compose and the Sandbox needs additional deployment specifications (Kubernetes/helm).

Responsibility: We need to put together a workflow that everyone can follow.

Common API endpoints for all BBs

An additional topic is about how the Sandbox team can push common APIs into BB definitions.

How should the workflow be setup?

How should the change request be specified?

Who does the review work for each BB and who maintains the mock/emulator implementation and the specification?

bb-template

Can the Sandbox team benefit from making minimal reference implementations available in the bb-template?

i.e. https://github.com/GovStackWorkingGroup/bb-template/issues/13