Page Comparison

Updates

Dominika Bieńkowska (Deactivated)

• API Testing - status across BBs

• http://testing.govstack.global/
  

• Implementation of dynamic data solution

• openIMIS integration into Digital Registries BB

• Payments BB improvements

• Use CaseExample Implementation

• Workflow BB

  • Mock server implementation

  • Sreepathy H Vardarajan has debugged the solution and has found some issues

  • In case Sreepathy H Vardarajan needs any help from us, he will reach out to us next week

• Benjamin is still working on closing some parts of Consent BB

  • Hopefully next week we can take over the work from Consent BB

Further priorities

Dominika Bieńkowska (Deactivated)

• API Testing Roadmap
  

• openIMIS integration into Digital Registries BB finalization

• openIMIS integration into Payments BB

• Online Construction Permits Use Case Example Implementation

• ?

Changes in APIs - how it should be addressed

Steve Conrad

• There are some changes to BB APIs

• Two topics to discuss on this one:

  • What should the process be when the spec is changed?

    • Any API changes have to be communicated

      • An API should happen as a PR and that should be the only way for all the changes to the API

        • All other actions needs to be taken in order to approve and merge this PR, like tests changes, mocks changes

        • Maybe we could use the CODEOWNERS feature on GitHub to mark ownership of the api/ folder?

      • As a next step we should have Payments BB to create a PR with all the API changes Kibuuka, Arnold

      • Proposal re: Karim's note: In order to work on both API v 1.x and v2.x at the same time,  we need long-lived release branches in Git, rather than just a "main" branch.

    • What if there is a change in tests but not a change in APIs?

      • If new tests are added, the compliance level might drop

      • It’s also important to define how do we want to communicate changes in tests

      • It

    • Is it possible to add automation?

  • Versioning - how exactly we want to do that?

    • Do we want tests to be a part of specifications?

      • Patch releases could be a good idea once the tests are changed

      • Steve Conrad will add this topic as agenda item to the TC

    • Add version branches to github?

    • We would need some examples to see how this process could look like

    • The testing app would need to be able to navigate through different branches

    • Steve

      • 2 possibilities:

        • Create folders for specific versions

        • Different versions are stored in permanent git branches

        I think the second would be preferable if the testing app is able to read from different git branches. We'd also need to be able to tag some branches as ones we want to run tests against

    • Paweł Gesek and Damian Borowiecki (Deactivated) will prepare a proposal for this and we will discuss it during TC

      • Test Suite Versioning ← document prepared by Damian Borowiecki (Deactivated), to review and check

Emulators

Benjamin Balder Bach

• Decision: Emulator solutions live in BB repositories in examples/ folder and have same entrypoint and Docker Compose setup

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

Real testing strategy and separation of responsibility for integration testing, calls to sandboxed BBs,

Mocks vs Emulators (ready to use products like Mocoon vs Emulator implementation,

deployability in sandbox)

Vasil Kolev

• Benjamin Balder Bach proposal to forward to TC:

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

  • Decision: Emulator solutions live in BB repositories in examples/ folder and have same entrypoint and Docker Compose setup

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

  • Consent BB can function as a POC

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

  • Need to solve terminology challenge: “examples/mock” doesn’t seem viable for the long-term. Could be “examples/mock-static“ or “examples/mock-simple“ + “examples/mock-advanced“?

UI redirects - BB Identity

Paweł Gesek

Mock application demo

Benjamin Balder Bach

AOB