Skip to content
This repository has been archived by the owner on Jul 29, 2024. It is now read-only.

spec/basic/synchronize_spec.js example doesn't seem to demonstrate waiting for timeouts #403

Closed
christothes opened this issue Jan 11, 2014 · 5 comments

Comments

@christothes
Copy link

In the 'spec/basic/synchronize_spec.js' example, there are some test that indicate they are waiting for time-outs versus not waiting however both tests look the same.

Is this a bug, or am I missing some detail here? What is the correct way to click a button that generates a server call and wait for it to return before testing the change to the page?

@juliemr
Copy link
Member

juliemr commented Jan 12, 2014

I believe you're referring to this test

  it('DOES NOT wait for timeout', function() {
    var status = element(by.binding('slowTimeoutStatus'));
    var button = element(by.css('[ng-click="slowTimeout()"]'));

    expect(status.getText()).toEqual('not started');

    button.click();

    expect(status.getText()).toEqual('pending...');
  });

To answer your first question: Note that the last line expects the status to be 'pending' instead of 'done', as the other tests do. The difference is that Angular/Protractor doesn't know about your custom timeout calls, so it can't wait for them to finish. However, Angular does know when you use $timeout or $http, so it can do the right thing there.

So for your second question, as long as your button uses $http at some level, you shouldn't have to do anything special at all to wait!

@juliemr juliemr closed this as completed Jan 12, 2014
@christothes
Copy link
Author

Thanks, makes sense. In my case the button click invokes a $Location change. The target route's Controller init is what issues the $http call. In this scenario is it possible to auto wait around this indirect $http call? I resorted to using setTimeout, which works, but seems hacky.

@juliemr
Copy link
Member

juliemr commented Jan 12, 2014

@christothes if that doesn't work currently, it should be supported. I'll try to make a test case in the example app that finds the issue.

In the meantime, using browser.wait() is preferable to setTimeout.

@christothes
Copy link
Author

In case you want to see how I'm reproducing it now:
Test:
'https://github.com/amirrajan/nodejs-against-humanity/blob/master/e2e-test/e2eTest.js#L21'

Relevant Code:
Click Target: https://github.com/amirrajan/nodejs-against-humanity/blob/master/views/index.html#L27
Indirect $http call: https://github.com/amirrajan/nodejs-against-humanity/blob/master/public/js/app/controllers.js#L223 -> https://github.com/amirrajan/nodejs-against-humanity/blob/master/public/js/app/services.js#L37

BTW, I did try browser.wait(), but it didn't seem to work in the above test. I tried with and without setting browser.ignoreSynchronization

@juliemr
Copy link
Member

juliemr commented Jan 12, 2014

May be a dupe of #255

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants