alecandido
commented
2 months ago Avoiding a connection when possible, and testing as much as possible even in unit test is even better, since more detailed and informative.
Open alecandido opened 2 months ago
alecandido
commented
2 months ago Avoiding a connection when possible, and testing as much as possible even in unit test is even better, since more detailed and informative.
One of the main motivations for Qibolab 0.2 is an attempt to review and stabilize the API, such that the development of platforms and Qibocal can happen on top of a stable Qibolab, making the development more decoupled (i.e. you don't need to update Qibolab because you want to do something in Qibocal - Qibolab is what it is, as if it were NumPy - worst case, you need Qibolab to roll out support for some features to do some development in Qibocal, and wait until is available).
However, testing and developing Qibolab is an entirely different story, since it is the upstream dependency.
We should not worry too much of breaking Qibocal from now on, since we'll swap this concern for the integrity of the public API (guaranteed by unit tests, as much as possible). This should help not only preserving Qibocal, but also whatever other user Qibolab has.
Still, we will need some more complex tests to be run on hardware - and possibly for which inspecting the resulting program/configurations. That's what I'm calling "integration tests". We can focus on a minimal number of experiments, and reproduce them in a very simplified way, attempting to assert something about the result - or just show some plots if asserts are not possible or sufficiently representative. This should be done, as much as possible, without Qibocal - though some minimal platform information will be needed just to access the hardware.
E.g. we can code the sequence for single-shot classification, and a minimal "qubit fit". And then routine with sweepers (e.g. Rabi) and multiple sweepers of different kinds (parallel & nested, various parameters, including channels ones).
Having these tests as lightweight as possible, and independent of Qibocal, would greatly help decoupling the development, and consequently making it simpler and faster (since Qibocal branches should not be updated simultaneously to properly test on hardware).
Notice that these tests, or at least part of them, could be also written as usage examples, and included in the docs.