Closed pehamTom closed 2 months ago
Just a quick side comment: should we really have (unit)tests that take up to 10 seconds and run them regularly on every pull request and push to main?
I guess it is worse than that. It actually takes more than 10 seconds. However, this method ensures that the entire functionality is actually tested. I know how to speed this process up by parallelizing the asynchronous calls to the SAT solver, but I haven't gotten around to that yet.
The alternative is to not test these instances, I guess.
Couldn't you "just" test smaller instances? Coverage-wise, that should still result in roughly the same coverage, right?
Couldn't you "just" test smaller instances? Coverage-wise, that should still result in roughly the same coverage, right?
Currently I am testing Steane and Surface code in the unittests. For the Steane code it is fast enough but for the Surface code it seems to take a while. The reason I use the surface code is that it is not self-dual, and thus, synthesizing |+> and |0> will give me different circuits, which I wanted to make sure of. But I can drop that requirement as well, I guess
@burgholzer now it should be better.
Description
Sometimes the python tests for the state preparation synthesis fail due to a timeout in the optimal synthesis. This PR removes some of these costly tests.
Checklist: