docs: add dedicated router testing guide #62445
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Deployed adev-preview for 3b2f36e to: https://ng-dev-previews-fw--pr-angular-angular-62445-adev-prev-wbsw2qej.web.app Note: As new commits are pushed to this pull request, this link is updated after the preview is rebuilt. |
JeanMeche
reviewed
Jul 2, 2025
eneajaho
suggested changes
Jul 3, 2025
atscott
requested changes
Jul 7, 2025
37e39c7 to
16782c4
Compare
16782c4 to
9bbcadd
Compare
atscott
reviewed
Jul 10, 2025
91d05d4 to
83634f9
Compare
JeanMeche
reviewed
Jul 14, 2025
83634f9 to
3b2f36e
Compare
|
/gemini review |
Comment on lines
+342
to
+344
| this.route.queryParams.subscribe(params => { | ||
| this.searchTerm = params['q'] || null; | ||
| }); |
There was a problem hiding this comment.
The subscription to queryParams is not unsubscribed, which can lead to a memory leak if the component is destroyed before the observable completes. Use takeUntilDestroyed to automatically unsubscribe when the component is destroyed.
Suggested change
| this.route.queryParams.subscribe(params => { | |
| this.searchTerm = params['q'] || null; | |
| }); | |
| import { takeUntilDestroyed } from '@angular/core/rxjs-interop'; | |
| constructor() { | |
| this.route.queryParams.pipe(takeUntilDestroyed()).subscribe(params => { | |
| this.searchTerm = params['q'] || null; | |
| }); | |
| } |
There was a problem hiding this comment.
Probably want toSignal instead
atscott
reviewed
Jul 15, 2025
|
|
||
| ## Best practices for router testing | ||
|
|
||
| 1. **Use RouterTestingHarness** - For testing routed components, use [`RouterTestingHarness`](api/router/testing/RouterTestingHarness) which provides a cleaner API and eliminates the need for test host components. It offers direct component access, built-in navigation, and better type safety. |
There was a problem hiding this comment.
You can maybe mention that RouterTestingHarness isn't suitable for all advanced use-cases and you might instead need to create your own host components for named outlets, for example.
atscott
reviewed
Jul 15, 2025
| 3. **Test navigation state** - Verify both the navigation action and the resulting application state, including URL changes and component rendering. | ||
| 4. **Handle asynchronous operations** - Router navigation is asynchronous. Use `async/await` or [`fakeAsync`](api/core/testing/fakeAsync) to properly handle timing in your tests. | ||
| 5. **Test error scenarios** - Include tests for invalid routes, failed navigation, and guard rejections to ensure your application handles edge cases gracefully. | ||
| 6. **Do not mock Angular router.** Instead, provide real route configurations and use the harness to navigate. This makes your tests more robust and less likely to break on internal Angular updates. |
There was a problem hiding this comment.
Suggested change
| 6. **Do not mock Angular router.** Instead, provide real route configurations and use the harness to navigate. This makes your tests more robust and less likely to break on internal Angular updates. | |
| 6. **Do not mock Angular router.** Instead, provide real route configurations and use the harness to navigate. This makes your tests more robust and less likely to break on internal Angular updates. |
And/or more likely to catch real issues due to changes in Angular. e.g. if the Router behavior changes in a way that breaks your application, a mock would prevent you from observing that breaking change
atscott
reviewed
Jul 15, 2025
| ## Best practices for router testing | ||
|
|
||
| 1. **Use RouterTestingHarness** - For testing routed components, use [`RouterTestingHarness`](api/router/testing/RouterTestingHarness) which provides a cleaner API and eliminates the need for test host components. It offers direct component access, built-in navigation, and better type safety. | ||
| 2. **Mock external dependencies** - When testing components that use routing, mock any external services or dependencies to focus your tests on routing behavior. |
There was a problem hiding this comment.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
Issue Number: N/A
What is the new behavior?
Adds a dedicated testing guide for router.
Does this PR introduce a breaking change?
Other information