0

The Detox test framework, according to the documentation TroubleShooting Synchronization mentions that the test framework will wait and only perform your next test statement when the app is "Idle".

The problem I have right now is that my app never goes idle because there's some timeout that's continuously firing. It could be in my code or third-party code.

Here's an example of the output:

Detox info log

As you can see something is creating a new timer every few milliseconds. What'd I'd like to do is track down which one, I can see the ids but don't know a good way to try and track down exactly where this (setTimeout) id is coming from.

  • I thought of wrapping the setTimeout function, but not sure what's the best way to proceed with that.
  • I could eliminate or at least wrap setTimout in my own code, that way, at least determining it's a third-party lib (which still doesn't help solve the problem).
Byron
  • 1,091
  • 11
  • 27
  • Not an answer but helped me towards a solution. Inside `./node_modules/detox/src/client/actions/actions.js` there is a class called `CurrentStatus` where the following line was commented out: `//console.log("res:" + JSON.stringify(response, null, 2));` inside the `handle` method. It gives much more robust information about where the timers are being set. Hope that helps. `Detox 11.0.1` – funador Mar 20 '19 at 16:40

1 Answers1

0

You could track down setTimeouts easily with:

 // DEV mode only!
 function failOnTimeout(func) {
   const setTimeout = f => {
     throw new Error(`Executing timeout \n ${f.toString()} \n`);
   };

   // A small trick to change scope:
   eval("(" + func.toString() + ")()");
}

So you can do:

 failOnTimeout(someMysteriousFunction);

And will give you stack traces of the first timeout set in that function (synchronously). You can then comment that out and search for the next one.

But instead of trackig down all timeouts, a quick solution could be to just throw an uncatched error to end the process.

Jonas Wilms
  • 132,000
  • 20
  • 149
  • 151