How does waitForAngularEnabled work?

前端 未结 3 643
暗喜
暗喜 2020-12-09 16:54

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

相关标签:
3条回答
  • 2020-12-09 17:21

    As an addition to the answer of Will, using waitForAngularEnabled multiple times in the same test can be done, but requires a non-obvious addition of browser.get. Intuitively, most people think that setting waitForAngularEnabled(true) waits for protractor to pick up Angular tasks again but this returns a promise. Most people use it in a way where they can disable it on non-Angular pages and re-enable it on Angular pages, aka in a synchronous way. To solve this, you can use the following:

    // do things on your Angular application
    
    waitForAngularEnabled(false)
    
    // do things on non-angular page
    
    waitForAngularEnabled(true)
    browser.get('/home') // this is a page from your Angular application
    

    The browser.get function blocks until the Angular page is loaded.

    0 讨论(0)
  • 2020-12-09 17:28

    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.

    0 讨论(0)
  • 2020-12-09 17:38

    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.

    0 讨论(0)
提交回复
热议问题