Open callumforrester opened 3 months ago
@callumforrester could you please elaborate what kind of tests do you have in mind?
@stan-dot updated issue description
how does this relate to the existing tests? @callumforrester
https://github.com/DiamondLightSource/i22-bluesky/blob/main/tests/plans/test_stopflow.py
They specifically only the test the sequence table creating part of the plan, not the poking devices part
ah right, thanks
I infer that this means those plans are to be ran on the machine live with real PVs on a testing day, right?
No, they are unit tests, they test pure functions. The ophyd-async tests I linked only test with mocked devices. The purpose of this ticket is to produce tests that are run in CI and exercise this code regularly to make sure it doesn't break.
ok, thanks for the clarification.
would it be good to make predictable testig on the machine day through defining the tests in a similar way though?
this sounds like it would work very similarily
studying the example you provided, @callumforrester
The way I see it, it tests the interface by putting it in a plan, but the plan is interspersed with assert
statements.
i22 stopflow is not an interface, but a plan too itself.
here's where from my understanding we can either call the whole plan but then the asserts won't be so interspersed, OR we copy paste the plan and add asserts there but then if the original plan changes it's of little meaning if the previous plan passes.
I think I'd like to gather more examples of how this has been done so far, maybe at MX?
The stopflow plan should have unit tests to ensure it is covered and the code is exercised regularly.
The unit tests for flyscanning in ophyd-async should provide a starting point: example.
Acceptance Criteria