There used to be a --no-artificial-delay flag on dfx start. This was very nice for integration tests, where you want to run your tests against the canister locally to emulate production as closely as possible.
Without that flag, running 100s or 1000s of tests will be infeasible in short amounts of time. At Demergent Labs we’re about to start in-depth property tests for the Azle and Kybra CDKs, where we generate arbitraries that create many many inputs, possibly 100s, 1000s, or even more. Having to wait for update calls to finish locally I foresee being a major source of unnecessary latency in our tests.
And I know about other testing paradigms where you might separate code from your canister to test it separately. That may be sufficient for some use cases, but I also want the ability to test my code directly from within a canister, as this mimics the production environment much more closely.
@Seb@paulyoung@quint you may have experienced the need for this before as well, I would love to know if you still want this functionality.
+1 to this. I’m writing some unit tests right now and it isn’t feasible to do this locally right now because it takes so long. --no-artificial-delay feels extremely important for anyone doing testing locally.
We decided that we’d be happy to re-introduce the --no-artificial-delay flag. We’d get to it soon-ish (whenever someone feels they have the time), but I’d also be happy to approve a PR wink wink nudge nudge
I think for extensive test suites that would be perfect. I also wouldn’t mind being able to set arbitrary values so people would type e.g. --artificial-delay 17, and it would have a default value of the current 500ms
We were thinking of a global settings file already for some customisation. Sounds like a good idea to me.