How Protractor’s Automatic Angular Wait Improves Test Reliability (and When to Turn It Off)

The problem: flaky tests in AngularJS apps

When you write end‑to‑end tests for an AngularJS application, the most common source of flakiness is timing. A click may happen before a $http request finishes, or a model update may still be pending when you assert the DOM. Traditionally teams sprinkle browser.sleep or explicit ExpectedConditions throughout the test suite, which makes the code brittle and slows down execution.

Thesis: Protractor’s built‑in waitForAngular eliminates most explicit waits

Protractor ships with a mechanism called waitForAngular. Before each WebDriver command it polls the Angular injector to see if there are any outstanding $timeout or $http tasks. If the injector reports stability, the command proceeds; otherwise Protractor retries until the timeout expires. This automatic synchronization means that, for pure AngularJS pages, you can often write tests that look like plain Selenium scripts without any extra waits.

How waitForAngular works under the hood

The core loop lives in Protractor’s control flow. After receiving a command from the test, it:

1. Checks window.angular via browser.executeScript.
2. If Angular is present, it asks the injector for pending $http and $timeout tasks.
3. If any are found, it waits (default 11 seconds in Protractor 5.4+) and repeats the check.
4. When the injector reports zero pending tasks, the original WebDriver command is sent to the browser.

Because the check is performed before every action, you rarely need to wait for a specific request to finish; the framework does it for you.

Worked example: testing a button that loads data via $http

Consider this minimal AngularJS page (index.html):

<!doctype html>
<html ng-app>
<head>
  <script src=\"https://ajax.googleapis.com/ajax/libs/angularjs/1.8.2/angular.min.js\"></script>
</head>
<body>
  <button ng-click=\"load()\">Load data</button>
  <div id=\"output\"></div>
<script>
  function load() {
    $http.get('/api/data').then(function(resp) {
      document.getElementById('output').textContent = resp.data;
    });
  }
</script>
</body>
</html>

A Protractor spec that clicks the button and asserts the response appears needs no explicit wait:

describe('Data load', function() {
  it('should show the server response after clicking', function() {
    browser.get('http://localhost:8080/index.html');
    element(by.buttonText('Load data')).click();
    expect(element(by.id('output')).getText()).toEqual('expected payload');
  });
});

When you run this test (protractor conf.js), Protractor will:

• Navigate to the page.
• Before the click, verify Angular has no pending $http calls (none yet).
• After the click, before the next command (the getText), it polls the injector until the $http callback finishes and the injector reports stability.
• Only then does it read the #output element and make the assertion.

You can verify the behavior by adding a console log in the $http callback and observing that the test does not proceed until the log appears.

When to disable the automatic wait

Protractor assumes every page it touches is AngularJS. If you need to interact with a non‑Angular iframe, a legacy server‑rendered page, or a hybrid app that mixes Angular with React/Vue, the waitForAngular poll will keep looking for an Angular injector that never appears, eventually timing out.

To bypass the wait for a specific action, set:

browser.ignoreSynchronization = true;
// perform your non‑Angular interaction
browser.ignoreSynchronization = false;

Leaving ignoreSynchronization true globally is risky: Protractor will no longer detect Angular‑specific errors (e.g., a failed $digest) and may report false‑positives.

Trade‑off and limitation

The main trade‑off is predictability versus flexibility. Automatic waiting removes boilerplate but couples your test speed to the longest Angular asynchronous task in the application. If a single $timeout lingers (perhaps due to a mis‑configured service), every test will wait up to the configured timeout.

You can adjust the timeout in your Protractor configuration:

exports.config = {
  allScriptsTimeout: 20000, // 20 seconds instead of the default 11 s
  // … other config
};

To check that the change took effect, run a test that deliberately triggers a long $timeout (e.g., setTimeout(function(){}, 15000);) and measure the total execution time; it should approach the new limit rather than failing early.

Actionable closing

If your project is pure AngularJS (≤ 1.8), keep waitForAngular enabled and enjoy cleaner, more reliable tests. When you encounter non‑Angular contexts, wrap those interactions with browser.ignoreSynchronization = true and restore it immediately afterward. Periodically review your allScriptsTimeout value to ensure it matches the slowest legitimate asynchronous operation in your app—too short and you’ll see spurious timeouts; too long and your suite will crawl.