You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: