feat(cdk/testing): cdk/testing should not depend on @angular/core

[yjaaidi]

Feature Description

As discussed today during the test harnesses community chat (AngularCommunity/angular-missions#5), it was noticed that @angular/cdk/testing depends on @angular/core/testing which depends on @angular/core due to the following import:

components/src/cdk/testing/testbed/testbed-harness-environment.ts

Line 18 in f94181a

import {ComponentFixture, flush} from '@angular/core/testing';

The flush function which is imported in order to handle fake async tests ends up importing @angular/core.
(I think that ComponentFixture isn't a problem because it is only used as a type so it's not bundled.)

The problem with this is that libraries like cypress-harness which depend on @angular/cdk/testing end up loading @angular/core and eventually slowing down tests as mentioned here jscutlery/devkit#6.
It's not just a performance issue but it feels wrong to always depend on @angular/core just because fake async tests need flush.

😅 It's too late in the evening for my brain to come up with precise suggestions... but I can hear some voices in my head:

• Dependency Inversion
• Move fake async to @angular/core/testing/fake-async or such
• YOLO, Please Repeat Yourself (cc. @jeffwhelpley 😉): _Zone && _Zone[_Zone.__symbol__('fakeAsyncTest')].flush()

[LayZeeDK]

import type {ComponentFixture} from '@angular/core/testing';

[LayZeeDK]

I see that flush is used by the local detectChanges function which is only used by Angular Material (experimental) tests and TestbedHarnessEnvironment#waitForTasksOutsideAngular which you probably don't depend on when implementing your own harness environment.

[angular-robot]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

[angular-robot]

Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

You can find more details about the feature request process in our documentation.