quasicomputational
commented
5 years ago I've just tried this out, dropping this branch in instead of some local code that implemented async timers, and I hit some snags along the way - but, once I overcame them, I can report it worked fine. I do have one problem to report. Specifically, sequential calls to runAllAsync can fail to be idempotent, which is quite contrary to my expectations - since, if it runs the queue to exhaustion, how can a second call find any more timers to run?
If I don't flush the timer queue at the end of every test, my tests stall and time out. OK, so I need to write my tests like this:
const itAsync = (name, fn) => {
it(name, async () => {
fn();
await clock.runAllAsync();
// D
});
};
itAsync("flarbs the blah", async () => {
// A
await clock.runAllAsync();
// B
await clock.runAllAsync();
// C
});Unfortunately, concurrent runAllAsync didn't behave like I wanted it to. The order of execution I observed was ABDC, as opposed to the hoped-for ABCD. This is quite problematic for me, since then the code at C runs after Jest considers the test to be over and done with.
If, however, itAsync is written like this:
const itAsync = (name, fn) => {
it(name, async () => {
let running = true;
Promise.resolve(fn()).finally(() => {
running = false;
});
while (running) {
await clock.runAllAsync();
}
});
};Then it works, and the code at C gets run before the end of the test. But this is clearly demonstrating that runAllAsync isn't idempontent. I think it'd be better if, even with multiple concurrent invocations, runAllAsync was guaranteed to be idempotent.
benjamingr
dominykas
fatso83
voxpelli
mroderick
This is a rebased and updated version of #105.
I still have to do a full review and test in our code base, probably might need to update some documentation, but just wanted to open this up. I probably also need to re-read all the threads on this... But hopefully this is now closer to getting merged than it was before :)