GitLab

changed milestone to %SoAR-2023W01

added Status::Sprint Backlog label

added Partner::NOC label

Am going round in circles thinking about how to move the existing adapter code into its own git repo. Do we:

1. Have a single repo containing the adapter code in multiple languages?
2. Have a separate repo for the adapter in each language?
3. In either case where does the SoAR protocol implementation code live?

I'm leaning towards option 2 because it's easier to test / CI / version. If different people are writing the ports then they're likely to diverge. Because the actual protocol is separate the version numbers don't have to track. Also if we identify a bug it's relatively likely to be language specific so it probably doesn't make sense to implement the same fix across each port.

So then what I guess we'd do is have a shared mock backend and a suite of tests which each language had to implement.

On question 3. The only role I can think of for a generic SoAR protocol implementation would be to pass the version rather than the schema and have the constructor retrieve the schema but I don't think that's worth doing and it changes the constructor signature. I think probably we just have the generic protocol that implements validation against the passed schema and give you a stub decode/encode method and then you extend that with the bespoke implementation for your client which is one fewer layer.

How do you run conceptually the same suite of tests across multiple repos with code written in different languages and stop the tests from diverging over time?

Potentially we could set up a bunch of fixtures and test definitions in a repo and then fork it for each adapter language repo. Then if we added new tests we'd add the fixtures and test definitions first and then merge the upstream into each fork to implement them.

Wouldn't stop them diverging if there wasn't resource available to do the work on each language port but it would give us a mechanism for tracking the work required to keep them consistent.

What we could do is use Gherkin to write a bunch of bdd features and then each language can implement the appropriate framework to run the same tests:

• Python: Behave
• JS - Cucumber
• C# - SpecFlow

moved to backbone-adapter-python#1 (closed)

This is my test requirements file content:

git+https://git.noc.ac.uk/communications-backbone-system/backbone-adapter-testsuite.git@packages#egg=backbone-adapter-testsuite

So for now I've been running pip install -r requirements.txt --upgrade -t packages so the files end up somewhere I can find them easily (packages/testsuite/features, packages/testsuite/fixtures).

Ultimately - you'd just do pip install -r requirements.txt and have a script to run post install that moves the features and fixtures from the module install location into view.