fix(core): ComponentFixture autodetect should detect changes within A… #54733
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…pplicationRef.tick
The current behavior of
autoDetect
inComponentFixture
does not match production very well. It has several flaws that make it an insufficient change detection mechanism:ApplicationRef
. This can cause real behavior differences that break in production, because tests can observe view refreshes in the incorrect order (for example, a dialog refreshing before the component which opened it).ApplicationRef.tick
already happen.onMicrotaskEmpty
subscription by not reporting them to the error handler. Instead, this error ends up being unhandled in the subscription and rxjs throws these in asetTimeout
.All of the above are problematic but this commit does not fix the final point. Ideally, we can land this in a future change but this requires additional internal fixes. In the meantime, we have to juggle special-case handling of the component fixture views within
ApplicationRef.tick
using some special events to retain current behavior and avoid errors from the fixture propagating to theErrorHandler
.BREAKING CHANGE: The
ComponentFixture.autoDetect
feature now executes change detection for the fixture withinApplicationRef.tick
. This more closely matches the behavior of how a component would refresh in production. The order of component refresh in tests may be slightly affected as a result, especially when dealing with additional components attached to the application, such as dialogs. Tests sensitive to this type of change (such as screenshot tests) may need to be updated. Concretely, this change means that the component will refresh before additional views attached toApplicationRef
(i.e. dialog components). Prior to this change, the fixture component would refresh after other views attached to the application.