Protractor does not wait to resolve promises on routes

[Zaylril]

Hey,

I'm having a few issues getting protractor to wait for my dependencies to load in the route.

The basic code I have is this (which works fine in Angular itself)

$routeProvider.when('/login, {
    templateUrl: 'template.html',
    controller: 'LoginCtrl',
    resolve: {
         dependencies: function($q, $rootScope) {
          var def = $q.defer();
          yepnope([
            {
                load: [
                    'dependencies.js',
                ],
                complete: function () {
                    $rootScope.$apply(function () {
                        def.resolve();
                    });
                }
            }
        ]);
        return def.promise;
        }
     }
 });

Protractor doesn't wait for the route to resolve and doesn't even display any content from the route. If the resolve dependency is removed the route successfully loads (but the test fails as the dependency isn't loaded).

I've tried it with $timeout testing and that works fine, and as this isn't a $http request, is there something I'm missing, or is this just not supported?

Thanks

[juliemr]

Hm, interesting. This works if you using $timeout inside resolve, as is used in this part of the testapp. I believe your example fails because you are making a custom promise. This seems like a reasonable use case - it will probably require some support from the Angular side, we'll investigate.

[morgs32]

I'm not one to +1 things, but this issue looked lonely.

edit: not an issue for me. had everything to do with fetching facebook login status in the promise. keep it up @juliemr and co

[yxh10]

Hi Julie @juliemr ,

I think I am having similar issue when using ui-router. According the doc https://github.com/angular/protractor/blob/master/docs/timeouts.md

and your comment, protractor waits for all $http and $timeout to finish, so I wrapped my resolve with $timeout.

Please see my code below to see what I mean (in fact, pretty much the same as the link you provided)

 $stateProvider
      .state('my.state',{
        url: '',
        templateUrl: 'my-state-template.html',
        controller: 'MyStateController',
        resolve: {
          contracts: ['myModelService', '$timeout', function(model, $timeout){
            return $timeout(function () {
              model.list();
            });
          }]
        }
      });

My test is working fine now, but I wonder if this is good practice? I am asking this because $timeout calls $apply and that fires digest cycle?

[yxh10]

I have just updated to 1.2.0 today. And everything is magically working fine now without $timeout. Thank you to all the protractor contributors. @juliemr

Updates:
OK. Sadly it was just my machine running a lot quicker after loading everything in memory. After I left this for some time and come back again, the same issue remains.

Thanks to @appsciences posting the stackoverflow link. To save a bit of time for other people, some one posted a word around on that page. Basically instead of relying on protractor to wait for the state/page to be resolved, wait for an element you expect to see.

browser.wait(function() {
    return $('#test321').isPresent(); // keeps waiting until this statement resolves to true
});

expect($('#test321').isPresent()).toBe(true);  

[appsciences]

Hello,

I'm on 1.4, and I am having the same issue as described above. More detail on stackoverflow.

[Smolations]

I am experiencing a similar issue. I'm using Angular 1.3.1, Protractor 1.4, and angular-ui-router 0.2.11. The app I am working with uses ocLazyLoad to resolve dependencies for various states. Many child states utilize a resolve function to load data from a service before changing state. I am one of the few developers using a Vagrant VM to do my development, so I run the protractor tests from my Mac host against the server in the VM. My colleagues all run the tests and server from their Macs, so they haven't noticed this issue because, I guess, the processing is fast enough that the tests seem to pass consistently for them?

I receive a NoSuchElementError fairly consistently in one of our tests. The relevant snippets are below for your consideration:

// right after the describe statement, these lines run with no problem
helpers.chrome.openUserMenu();
element(by.cssContainingText('#mainUserDropMenu a', 'Settings')).click(); // this triggers a state change
browser.waitForAngular();


// here are the original lines that fail for me in Vagrant, but pass for my colleagues.
// the NoSuchElementError is thrown on the second line.
var $registerLink = element(by.css('a[ui-sref="some.stateLink"]'));
expect($registerLink.getText()).toEqual('Register Now');


// after much fiddling and googling, i discovered that adding a simple
// line to check for presence (though I'm not doing anything with it)
// makes the test pass consistently:
browser.isElementPresent(by.css('a[ui-sref="some.stateLink"]')); // promise also happens to resolve successfully
var $registerLink = element(by.css('a[ui-sref="some.stateLink"]'));
expect($registerLink.getText()).toEqual('Register Now'); // works!


// i then found this issue and the relevant stack overflow post and the solution
// given in both also works:
var elem = by.css('a[ui-sref="some.stateLink"]');
browser.driver.wait(function() {
    return browser.isElementPresent(elem);
}, 5000);
var $registerLink = element(elem);
expect($registerLink.getText()).toEqual('Register Now'); // works!

The template loaded by the route that contains the element in question is loaded into a parent 'layout' which is loaded into a <ui-view> from the main html page served up by the server. The anchor element's text is static (not an expression) and its containing element contains no directives which determine how/if the element should be rendered.

I am not sure if this is a protractor issue or a UI Router/ocLazyLoad issue, but I wanted to follow up in this thread due to its relevancy to my problem. Perhaps the talented, protractor expert @juliemr could give an update as to this investigation? =]

[paulcwarren]

I take back what I said yesterday...

I thought I was having exactly this issue using protractor 1.6.1 on a fairly large project that I am retro-fitting e2e tests to.

HOWEVER, after putting together a quick, small angular app to test with and I can't reproduce the behavior described here and seen in my large production project. That said I am not sure how accurate my test app is since it uses $timeout (inside a angular service) to fake a $http call that takes "some time". I think I'll convert that to a long-running service on my server. IF I can repro it I will commit my test app, in case that helps protractor folks. Stay tuned.

UPDATE 02/07

In case it is useful to others.

Turns out my problem was actually a ui-bootstrap 0.11 carousel problem whose implementation uses $timeout, rather than $interval. Initially I was getting timeouts waiting for sync and this had forced me down the road of using ignoreSynchronization=true (although I was ignorant of exactly why at the time, just trying stuff out really). Ignoring sync then caused all sorts of knock on effects, such as not waiting for resolves ultimately getting me here. Once I ruled out this problem out with my test app (becuse it didn't repro this resolve issue) I went all the way back to basics, removing ignoreSynchronization=true getting the timeout issues and this time properly investigating it eventually narrowing it down to the carousel.

The carousel FR is documented here:-
angular-ui/bootstrap#1630

My conclusion, don't use ignoreSynchronization=true and the wait for resolve bug is fixed (protractor 1.6.1).

[facultymatt]

Im getting the same issue where resolves cause tests to fail, using ui-router v0.2.13.

[yxh10]

Guys please see the code below if your issue is timing related.You just need to ask Protractor to wait for the element to appear. Read the line with comment.

browser.wait(function() {
       return $('#test321').isPresent(); // keeps waiting until this statement resolves to true
      });

($('#test321').isPresent()).toBe(true); 

[Smolations]

@yxh10 That is not a long-term solution. Protractor should be aware of the views it's rendering, as well as when the DOM is ready. Using browser.wait in that fashion may solve the immediate problem, but if it happens across many tests, the spec files would be littered with all of those statements. Not only that, but how would one choose an appropriate timeToWaitInMilliseconds? Having multiple blocks such as the one you have above would significantly slow down testing for larger applications.

[yxh10]

@Smolations Hi, Chris, I agree with you. It is a work around. You could use this before protractor solve the problem from the core.

Regarding to choose approriate timeToWaitInMilliseconds, I am not sure if you are talking about the time you set in protractor config, or the time you set with browser.wait. If you are talking about the later, you actually don't need to worry about it. If you read the line that come with comment, and the api doc, you will realize it is returning a promise. The rest of the code will only run when the dom is presented (ready). It is exactly doing that. No time needed to be set. And if you want to wait till dom is actually displayed, you can use isDisplayed() instead of isPresent.

So the only downside of this solution for now is too wordy for now. (You can always write your own util function to wrap it which is what I am doing in my current project.) You don't really need to worry about setting the length of time you wait. It is all handled by brower.wait waiting for the promise returned inside.

[paulfreeman]

Also hitting problems with this today. Work around makes testing very slow, but at least it works. Note, I believe that the timeToWaitInMilliseconds must be long enough to allow the actual request to return, browser.wait will then wait up to that length of time, but will return sooner if the request does.

[yxh10]

@moneytree-doug , you could try the work around I posted above. But if your requirement is fine with mocked service, that is also cool. 👍