redux-saga-test-plan icon indicating copy to clipboard operation
redux-saga-test-plan copied to clipboard

Err on timeout

Open timm-aym opened this issue 6 years ago • 4 comments

We're using redux-saga-test-plan with jest, and I have recently started noticing timeout warnings printed to the console.

When I add a test like the first example on this page, it prints a warning, but the test still passes.

screen shot 2018-05-24 at 10 45 53

Is there a way to make timeouts fail the test?

timm-aym avatar May 24 '18 08:05 timm-aym

Hi, @timm-aym.

Timeouts are there by design if you have an infinitely running saga (i.e. use takeEvery or a while(true) loop) so they can be stopped after ample time has been given for your assertions to pass. In the example you mentioned, the test is passing as expected and then stops the saga with the timeout. You can silence warnings with silentRun. You can also decrease the timeout length if you think your assertions will come quicker than 250ms.

jfairbank avatar May 28 '18 19:05 jfairbank

But if I understand it correctly, when testing a saga and dispatching the wrong action, it would just stall on the take* and never finish, right? Or would the hasFinalState assertion still trigger?

We also tried an approach where we also dispatched END to the saga in order to stop it explicitly instead of via timeout, but that didn't end the saga. (If this should work, I would investigate this further.)

timm-aym avatar May 29 '18 06:05 timm-aym

We're also encountering discomfort with this.

I think for us, the problem comes where the default behavior of .run() isn't equivalent to .run(false). That the timeout is supported is nice, but none of our sagas run forever, so the major risk is that we run a test and it blocks on some precondition we forgot to specify, so the test passes (false positively) with a warning. We'd contrast this with the test blocking over mocha's timeout, thus failing the test.

I almost feel like you could say "if the argument to run is falsy, block" because that captures both run(false) and run() (same as run(undefined), but it also might loop in a bunch of cruft you don't care about, like run(0), run(NaN), run(null).

EDIT: Perhaps also run(true) could infer the default 250ms timeout?

Awesome library! This is really helping us to eliminate false positive results in our saga tests.

scottmmjackson avatar Nov 15 '18 21:11 scottmmjackson

We have a few tests on the main branch where the promise was just thrown away (stupid!). They timeout with a warning, but nobody noticed it for over a year. When you have a few hundred tests it's difficult to figure out which one times out, an error or a stack trace would help.

bdurrer avatar Jul 09 '19 07:07 bdurrer