Skip to content

fix(cdk/testing): fix behavior in fakeAsync tests #20638

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Oct 2, 2020

Conversation

mmalerba
Copy link
Contributor

No description provided.

@mmalerba mmalerba added the P2 The issue is important to a large percentage of users, with a workaround label Sep 23, 2020
@mmalerba mmalerba requested a review from a team as a code owner September 23, 2020 06:51
@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Sep 23, 2020
@@ -67,13 +67,22 @@ function uninstallAutoChangeDetectionStatusHandler(fixture: ComponentFixture<unk
}
}

/** Whether we are currently in the fake async zone. */
function isInFakeAsyncZone() {
return Zone?.current.get('FakeAsyncTestZoneSpec') != null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a Zone global variable isn't defined, this will still throw a TypeError. You'll have to guard it with typeof Zone !== 'undefined' to avoid the error, although I'm not sure how likely it is that we'll hit such a case.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed it back to ! which is what it actually was originally. I don't think we really support testing without zones currently anyways

Copy link
Member

@crisbeto crisbeto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@crisbeto crisbeto added the action: merge The PR is ready for merge by the caretaker label Sep 25, 2020
@mmalerba mmalerba added target: patch This PR is targeted for the next patch release target: minor This PR is targeted for the next minor release and removed target: patch This PR is targeted for the next patch release labels Oct 2, 2020
@mmalerba mmalerba merged commit 40fa9ff into angular:master Oct 2, 2020
@thw0rted
Copy link

I've been trying to start using the TestbedHarnessEnvironment for a couple of days now, and I've had a lot of trouble. The component under test uses setInterval internally to update a property, so in the unit test, fixture.whenStable() never resolves. I'm still able to directly manipulate the fixture using fakeAsync tests, with a discardPeriodicTasks() at the end of each test.

I tried following the docs for using harnesses but my tests timeout at await loader.getAllHarnesses(...). Am I right in thinking that this is because getAllHarnesses is currently using whenStable under the hood, and that this patch addresses my problem? (If so, any idea when I can expect this to land in a release?)

@crisbeto
Copy link
Member

@thw0rted I can't say whether it'll fix your problem, but the change is in the 11.0.0-next.1 release if you want to try it out.

@thw0rted
Copy link

Thanks @crisbeto, I will give it a shot.

I had meant my questions about behavior to be more aimed at @mmalerba, because the PR didn't have a description, nor did it link to an existing issue, so I had to try to guess at the motivation behind it. From the comments in the commits, it sounded sort of like what I was experiencing, but I wasn't sure.

@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Nov 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker cla: yes PR author has agreed to Google's Contributor License Agreement P2 The issue is important to a large percentage of users, with a workaround target: minor This PR is targeted for the next minor release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants