Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to track which async tasks protractor is waiting on?

Tags:

I have a medium sized Angular application and for some reasons some of my protractor tests are timing out when run against my live production environment.

I am fairly sure the timeouts happen because of protractor waiting on some asynchronous task. I know about zones and I tried to keep all long running async tasks out of the ngZone (as per the FAQ), but for some reason protractor is still timing out.

It's possible I missed something but I don't know how to debug the problem. Is there any way to find out which part of the code protractor is waiting on?

The NgZone only exposes functions to determine if there are microtasks or macrotasks running, but doesn't tell me which one.

EDIT: A typical example of such a timeout error as shown by protractor:

Failed: Timed out waiting for asynchronous Angular tasks to finish after 11 seconds. This may be because the current page is not an Angular application. Please see the FAQ for more details: https://github.com/angular/protractor/blob/master/docs/timeouts.md#waiting-for-angular

While waiting for element with locator - Locator: By(css selector, [data-e2e='scroll-to-offer'])

The element exists on the page (I have verified this manually), but protractor still times out.

like image 293
magnattic Avatar asked Feb 05 '18 16:02

magnattic


1 Answers

I had a similar problem, the Testability was unstable and all I knew is that I have some pendingMacroTasks. It's indeed a bit tricky to localize these tasks (you won't go through the whole code base and look for setTimeout).
However I managed to do this eventually.

Relatively simple solution

First thing you can do is open your Dev Tools in Chrome, press Ctrl+O, type zone.js and press Enter.
This will open zone.js source file (not Typescript, yet something).
Inside zone.js look for Zone.prototype.runTask and put a breakpoint inside this method.
Enable the breakpoint after your application is loaded, otherwise it will get hit too many times.

If your Testability is not stabilizing, it probably means that you have some repetitive macro task that reschedules itself. At least that was my case.
If this is the case, the breakpoint will get hit every X time after the application is loaded.

Once the breakpoint is hit, go to task.callback.[[FunctionLocation]] this will take you to (most probably) some setTimeout or setInterval.
To fix it run it outside of Angular zone.

A bit trickier solution

This involves tweaking the Zone.js code, but gives you a more persistent debug information.

  1. Go to node_modules/zone.js/dist/zone.js.
  2. Look for Zone's constructor function: function Zone(parent, zoneSpec)
  3. Add the following inside: this._tasks = {}
  4. Add counter variable in global scope: let counter = 0
  5. Look for Zone.prototype.scheduleTask and add the following right before the call to this._updateTaskCount(task,1):

    task.id = counter++; this._tasks[task.id] = task; 
  6. Look for Zone.prototype.scheduleTask and add the following right before the call to this._updateTaskCount(task,-1):

    delete this._tasks[task.id] 
  7. Recompile the application and run it

Assuming you did the above tweaks you can always access the pending tasks like this:

tasks = Object.values(window.getAllAngularTestabilities()[0]._ngZone._inner._tasks) 

To get all the pending macro tasks that affect the testability state:

tasks.filter(t => t.type === 'macroTask' && t._state === 'scheduled') 

After that similarly to the previous solution check out the .callback.[[FunctionLocation]] and fix by running outside of Angular zone.

like image 71
JeB Avatar answered Oct 05 '22 23:10

JeB