You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Those rewrites focus on using Vitest instead of jasmine, drop usages of `fakeAsync`, present modern testing strategy that rely on `whenStable` more than explicit calls to `detectChanges`.
fixes#42748, #48510, #64962, #65987, #66029, #66150
-**[`RouterTestingHarness`](api/router/testing/RouterTestingHarness)** - Test harness for testing routed components with built-in navigation and component testing capabilities
13
12
@@ -326,6 +325,6 @@ export class Search {
326
325
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. However, it isn't as suitable for some scenarios, such as testing named outlets, where you may need to create custom host components.
327
326
2.**Handle external dependencies thoughtfully** - Prefer real implementations when possible for more realistic tests. If real implementations aren't feasible (e.g., external APIs), use fakes that approximate the real behavior. Use mocks or stubs only as a last resort, as they can make tests brittle and less reliable.
328
327
3.**Test navigation state** - Verify both the navigation action and the resulting application state, including URL changes and component rendering.
329
-
4.**Handle asynchronous operations** - Router navigation is asynchronous. Use `async/await`or [`fakeAsync`](api/core/testing/fakeAsync)to properly handle timing in your tests.
328
+
4.**Handle asynchronous operations** - Router navigation is asynchronous. Use `async/await` to properly handle timing in your tests.
330
329
5.**Test error scenarios** - Include tests for invalid routes, failed navigation, and guard rejections to ensure your application handles edge cases gracefully.
331
330
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, while also ensuring you catch real issues when the router updates since mocks can hide breaking changes.
An _attribute directive_ modifies the behavior of an element, component or another directive.
4
4
Its name reflects the way the directive is applied: as an attribute on a host element.
5
5
6
-
## Testing the `HighlightDirective`
6
+
## Testing the `Highlight` directive
7
7
8
-
The sample application's `HighlightDirective` sets the background color of an element based on either a data bound color or a default color \(lightgray\).
8
+
The sample application's `Highlight` directive sets the background color of an element based on either a data bound color or a default color \(lightgray\).
9
9
It also sets a custom property of the element \(`customProperty`\) to `true` for no reason other than to show that it can.
Testing the specific use of the `HighlightDirective` within the `AboutComponent` requires only the techniques explored in the ["Nested component tests"](guide/testing/components-scenarios#nested-component-tests) section of [Component testing scenarios](guide/testing/components-scenarios).
It's used throughout the application, perhaps most simply in the `About` component:
32
+
33
+
```ts
34
+
@Component({
35
+
imports: [Twain, Highlight],
36
+
template: `
37
+
<h2 highlight="skyblue">About</h2>
38
+
<h3>Quote of the day:</h3>
39
+
<twain-quote />
40
+
`,
41
+
})
42
+
exportclassAbout {}
43
+
```
44
+
45
+
Testing the specific use of the `Highlight` directive within the `About` component requires only the techniques explored in the ["Nested component tests"](guide/testing/components-scenarios#nested-component-tests) section of [Component testing scenarios](guide/testing/components-scenarios).
0 commit comments