How does waitForAngularEnabled work?

问题:

I am curious how does waitForAngularEnabled() work? Though it doesn't seem complicated, however, I couldn't get any satisfied answers anywhere. So hopefully someone helps me get cleared.

My goal is to check criteria and pause/lock running test until the criteria is meet. Here are cases for example.

A. to pause running test and wait until page gets loaded

    ...
    let theElement = ...;
    browser.waitForAngularEnabled(false);
    browser.wait(protractor.ExpectedConditions.presenceOf(theElement));

B. to use browser.wait(), the alternative way for similar purpose with A

    browser.wait(() => {
        browser.waitForAngularEnabled(false);
        return browser.isElementPresent(by.id('the-element-id'));
    }, timeout); // timeout may not be given

So the question is:

1. What will happen once waitForAngularEnabled(false) is invoked? (once the criteria is meet or timeout occur in my case)
2. Should I revert waitForAngularEnabled(true) to continue normal testing?
3. If I should do, where to put it?

Hope to get clear answers with some background principle.

Thanks!

回答1:

1. What will happen once waitForAngularEnabled(false) is invoked? (once the criteria is meet or timeout occur in my case)

Empirically I have found that this seems to cause Protractor to behave as merely Webdriver. It does not wait for Angular to "settle down" (no pending HTTP requests or view updates), which is the behavior for true. Instead, if you use the false setting, you will need to use ExpectedConditions or similar approaches in order to verify preconditions to execute test steps reliably, just as you would with an ordinary Webdriver test.

2. Should I revert waitForAngularEnabled(true) to continue normal testing?

Yes. However, I have found that in Protractor 5.1.1 and 5.1.2, whether using control flow or not, scattering different waitForAngularEnabled values throughout your tests in the same execution seems to yield unpredictable results; that is, the enabled state does not follow the same asynchronous semantics of other Protractor/Webdriver calls. So far, my conclusion is that you cannot reliably mix waitForAngularEnabled(false) and waitForAngularEnabled(true) in the same execution. I suspect that this is a Protractor bug, but I have not yet developed a simple and reliable test to prove it in support of submitting a Protractor issue. There was a possibly related issue here, now closed but incompletely diagnosed.

3. If I should do, where to put it?

"Before" you make Protractor/Webdriver calls that require restoring the waiting-for-Angular semantics. However, as mentioned above, it's not clear that you can reliably guarantee that such calls will truly be made in the context of the true setting.

If you must have some tests that use false and others true, you could run them in separate executions (separate processes; don't run them with the same protractor or ng e2e command). I have encountered no problems when that approach is taken.

回答2:

The marked answer is good - still I'd like to answer your question with added details about browser.get:

To override the default behavior of Protractor to wait for Angular calls, we can disable the Angular wait with browser.waitForAngularEnabled(false). For the rest of the driver session, Protractor will not sync the Angular calls unless Angular wait is enabled using: browser.waitForAngularEnabled(true).

But I recommend using wrapped driver directly instead of toggling the waitForAngularEnabled property which can lead to an unstable script. We had an issue with parallel test execution (which we definitely didn't want to run sequentially) - which is obvious when all tests set waitForAngularEnabled concurrently.

Protractor uses the testability APIs exposed by AngularJS functionalities like $q, $timeout, and $html to sync the page created by AngularJS asynchronous components.

browser.get When we call browser.get method in our script to navigate to a web page, Protractor uses the selenium-webdriver's get method to navigate to requested page and then by default tries to sync the page using AngularJS testability API.

Protractor’s waitForAngular strategy considers that the current page has AngularJS library and calls the getTestabilityAPI method on global object window.angular.

browser.driver.get When using Protractor with non-Angular application without overriding the default behavior, we get an error – angular is not defined because, by default, Protractor will try to synch the page using window. angular API which is not available on the page.