Integration tests are currently using a combination of bash scripts & cloud build settings to run a host of tests all part of one global config. This causes a few issues:
it's hard to isolate individual test cases to understand what is being covered
changing one test case can break other independent tests (e.g. having to update the build step names, or inserting into the one shared dicomstore)
cleanup is easy to miss
diff checks are just based on file comparisons which makes them hard to debug
Instead we can move towards using a proper language to write the tests (like Java or Python) that provides connivence methods for creating/cleaning up test environments. A design doc outlining this would be a good next step.
Filling this as a future cleanup.
Integration tests are currently using a combination of bash scripts & cloud build settings to run a host of tests all part of one global config. This causes a few issues:
Instead we can move towards using a proper language to write the tests (like Java or Python) that provides connivence methods for creating/cleaning up test environments. A design doc outlining this would be a good next step.