feat(cdk/testing): allow disabling & batching of change detection

[mmalerba]

This PR introduces 2 new APIs that give users more fine-grained control over change detection when working with harnesses:

• The first API, manualChangeDetection, can be used to disable the harness's automatic change detection for a block of code, e.g.

it('tests some things', async () => {
  await maualChangeDetection(async () => {
    someHarness.click();
    expect(...).toBe(...); // Check expectations before change detection...
    fixture.detectChanges();
    await fixture.whenStable();
    expect(...).toBe(...); // Check expectations after fixture stabilizes...
  });
});

• The second API, parallel, can be used to resolve several async values in parallel via Promise.all while also batching change detection so that it only happens once before resolving the values and once after. This is useful for optimizing the performance of tests, e.g.

it('tests some things', async () => {
  // Read labels for all buttons simultaneously,
  // rather than waiting for one before reading the next
  const buttonLabels = await parallel(() => buttonHarnesses.map(button => button.text()));
});

Using the new parallel in the HarnessPredicate resolution code results in a signigicant performance gain:

• finding a button by text on a page with 100 buttons: 1250.7ms => 131.8ms (89% improvement)

Using it in tests that perform many actions simultaneously again results in a significant performance gain:

• clicking 1000 buttons: 3009.8ms => 757.8ms (75% improvement)

[wagnermaciel]

lgtm

[mmalerba]

Feedback addressed

[jelbourn]

LGTM, just a few docs nits

[devversion]

LGTM. nice work. One comment that should resolve the CI failures you were seeing

[devversion]

If the specified function fails here, we will never restore the disabled state of the auto change-detection, and change detection will never run at all. This causes the CI failures you're seeing in the gulp jobs as those run all tests (like a usual CLI project) in a single Karma process. This is actually great as it unveiled this issue that could surface for consumers.

The fix is to wrap this with a try/finally and always restore the state of change detection. In tests, it can commonly happen that errors are expected & silently handled. In such situations consecutive tests just fail randomly with all kinds of errors as change detection for harnesses is disabled permanently (as seen with the CI failures for this PR; it was hard figuring out there is actually a "silent" error). It was a test in the radio harnesses using expectAsync and toBeRejectedWith 😄

// If the function fails, we still want to restore the auto change detection state as
// otherwise change detection could be disabled unexpectedly forever. In some cases,
// errors are expected in tests and therefore silently captured. This would mean that
// consecutive tests relying on auto change detection could break without any hint about
// disabled auto change detection.
try {
  result = await fn();
} finally {
  await new Promise(resolve => autoChangeDetectionSubject.next({
    isDisabled: false,
    onDetectChangesNow: resolve,
  }));
}

We also need to do the same below with triggerBeforeAndAfter = false.

[devversion]

For later reference: The select tests for example failed as selectHarness.open was not reflected due to disabled change detection. The options were undefined then and .click resulted in a runtime exception.

[mmalerba]

Thank you so much for looking into this! That makes total sense. I was going crazy trying to debug this on Friday

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}