docs: fix typos in the routing and testing documentation (#32329)
PR Close #32329
This commit is contained in:
parent
bbd4a33f6c
commit
5b2408f0a6
|
@ -477,8 +477,7 @@ which covers testing with the `HttpClientTestingModule` in detail.
|
||||||
|
|
||||||
A component, unlike all other parts of an Angular application,
|
A component, unlike all other parts of an Angular application,
|
||||||
combines an HTML template and a TypeScript class.
|
combines an HTML template and a TypeScript class.
|
||||||
The component truly is the template and the class _working together_.
|
The component truly is the template and the class _working together_. To adequately test a component, you should test that they work together
|
||||||
and to adequately test a component, you should test that they work together
|
|
||||||
as intended.
|
as intended.
|
||||||
|
|
||||||
Such tests require creating the component's host element in the browser DOM,
|
Such tests require creating the component's host element in the browser DOM,
|
||||||
|
@ -1120,7 +1119,7 @@ The first is a sanity test; it confirms that the stubbed `UserService` is called
|
||||||
<div class="alert is-helpful">
|
<div class="alert is-helpful">
|
||||||
|
|
||||||
The second parameter to the Jasmine matcher (e.g., `'expected name'`) is an optional failure label.
|
The second parameter to the Jasmine matcher (e.g., `'expected name'`) is an optional failure label.
|
||||||
If the expectation fails, Jasmine displays appends this label to the expectation failure message.
|
If the expectation fails, Jasmine appends this label to the expectation failure message.
|
||||||
In a spec with multiple expectations, it can help clarify what went wrong and which expectation failed.
|
In a spec with multiple expectations, it can help clarify what went wrong and which expectation failed.
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
@ -1143,7 +1142,7 @@ The `TwainComponent` displays Mark Twain quotes.
|
||||||
region="template"
|
region="template"
|
||||||
header="app/twain/twain.component.ts (template)"></code-example>
|
header="app/twain/twain.component.ts (template)"></code-example>
|
||||||
|
|
||||||
Note that value of the component's `quote` property passes through an `AsyncPipe`.
|
Note that the value of the component's `quote` property passes through an `AsyncPipe`.
|
||||||
That means the property returns either a `Promise` or an `Observable`.
|
That means the property returns either a `Promise` or an `Observable`.
|
||||||
|
|
||||||
In this example, the `TwainComponent.getQuote()` method tells you that
|
In this example, the `TwainComponent.getQuote()` method tells you that
|
||||||
|
@ -1156,7 +1155,7 @@ the `quote` property returns an `Observable`.
|
||||||
|
|
||||||
The `TwainComponent` gets quotes from an injected `TwainService`.
|
The `TwainComponent` gets quotes from an injected `TwainService`.
|
||||||
The component starts the returned `Observable` with a placeholder value (`'...'`),
|
The component starts the returned `Observable` with a placeholder value (`'...'`),
|
||||||
before the service can returns its first quote.
|
before the service can return its first quote.
|
||||||
|
|
||||||
The `catchError` intercepts service errors, prepares an error message,
|
The `catchError` intercepts service errors, prepares an error message,
|
||||||
and returns the placeholder value on the success channel.
|
and returns the placeholder value on the success channel.
|
||||||
|
@ -1251,9 +1250,9 @@ XHR calls within a test are rare, but if you need to call XHR, see [`async()`](#
|
||||||
You do have to call `tick()` to advance the (virtual) clock.
|
You do have to call `tick()` to advance the (virtual) clock.
|
||||||
|
|
||||||
Calling `tick()` simulates the passage of time until all pending asynchronous activities finish.
|
Calling `tick()` simulates the passage of time until all pending asynchronous activities finish.
|
||||||
In this case, it waits for the error handler's `setTimeout()`;
|
In this case, it waits for the error handler's `setTimeout()`.
|
||||||
|
|
||||||
The `tick()` function accepts milliseconds as parameter (defaults to 0 if not provided). The parameter represents how much the virtual clock advances. For example, if you have a `setTimeout(fn, 100)` in a `fakeAsync()` test, you need to use tick(100) to trigger the fn callback.
|
The `tick()` function accepts milliseconds as a parameter (defaults to 0 if not provided). The parameter represents how much the virtual clock advances. For example, if you have a `setTimeout(fn, 100)` in a `fakeAsync()` test, you need to use tick(100) to trigger the fn callback.
|
||||||
|
|
||||||
<code-example
|
<code-example
|
||||||
path="testing/src/app/demo/async-helper.spec.ts"
|
path="testing/src/app/demo/async-helper.spec.ts"
|
||||||
|
@ -1277,7 +1276,7 @@ It's a companion to `fakeAsync()` and you can only call it within a `fakeAsync()
|
||||||
Jasmine also provides a `clock` feature to mock dates. Angular automatically runs tests that are run after
|
Jasmine also provides a `clock` feature to mock dates. Angular automatically runs tests that are run after
|
||||||
`jasmine.clock().install()` is called inside a `fakeAsync()` method until `jasmine.clock().uninstall()` is called. `fakeAsync()` is not needed and throws an error if nested.
|
`jasmine.clock().install()` is called inside a `fakeAsync()` method until `jasmine.clock().uninstall()` is called. `fakeAsync()` is not needed and throws an error if nested.
|
||||||
|
|
||||||
By default, this feature is disabled. To enable it, set a global flag before import `zone-testing`.
|
By default, this feature is disabled. To enable it, set a global flag before importing `zone-testing`.
|
||||||
|
|
||||||
If you use the Angular CLI, configure this flag in `src/test.ts`.
|
If you use the Angular CLI, configure this flag in `src/test.ts`.
|
||||||
|
|
||||||
|
@ -1322,7 +1321,7 @@ If you run other `macroTask` such as `HTMLCanvasElement.toBlob()`, `Unknown macr
|
||||||
</code-pane>
|
</code-pane>
|
||||||
</code-tabs>
|
</code-tabs>
|
||||||
|
|
||||||
If you want to support such case, you need to define the `macroTask` you want to support in `beforeEach()`.
|
If you want to support such a case, you need to define the `macroTask` you want to support in `beforeEach()`.
|
||||||
For example:
|
For example:
|
||||||
|
|
||||||
```javascript
|
```javascript
|
||||||
|
@ -1351,7 +1350,7 @@ it('toBlob should be able to run in fakeAsync', fakeAsync(() => {
|
||||||
|
|
||||||
You might be satisfied with the test coverage of these tests.
|
You might be satisfied with the test coverage of these tests.
|
||||||
|
|
||||||
But you might be troubled by the fact that the real service doesn't quite behave this way.
|
However, you might be troubled by the fact that the real service doesn't quite behave this way.
|
||||||
The real service sends requests to a remote server.
|
The real service sends requests to a remote server.
|
||||||
A server takes time to respond and the response certainly won't be available immediately
|
A server takes time to respond and the response certainly won't be available immediately
|
||||||
as in the previous two tests.
|
as in the previous two tests.
|
||||||
|
@ -1366,9 +1365,8 @@ from the `getQuote()` spy like this.
|
||||||
|
|
||||||
#### Async observable helpers
|
#### Async observable helpers
|
||||||
|
|
||||||
The async observable was produced by an `asyncData` helper
|
The async observable was produced by an `asyncData` helper.
|
||||||
The `asyncData` helper is a utility function that you'll have to write yourself.
|
The `asyncData` helper is a utility function that you'll have to write yourself, or you can copy this one from the sample code.
|
||||||
Or you can copy this one from the sample code.
|
|
||||||
|
|
||||||
<code-example
|
<code-example
|
||||||
path="testing/src/testing/async-observable-helpers.ts"
|
path="testing/src/testing/async-observable-helpers.ts"
|
||||||
|
@ -1480,8 +1478,7 @@ is `undefined`.
|
||||||
|
|
||||||
Now you are responsible for chaining promises, handling errors, and calling `done()` at the appropriate moments.
|
Now you are responsible for chaining promises, handling errors, and calling `done()` at the appropriate moments.
|
||||||
|
|
||||||
Writing test functions with `done()`, is more cumbersome than `async()`and `fakeAsync()`.
|
Writing test functions with `done()`, is more cumbersome than `async()`and `fakeAsync()`, but it is occasionally necessary when code involves the `intervalTimer()` like `setInterval`.
|
||||||
But it is occasionally necessary when code involves the `intervalTimer()` like `setInterval`.
|
|
||||||
|
|
||||||
Here are two more versions of the previous test, written with `done()`.
|
Here are two more versions of the previous test, written with `done()`.
|
||||||
The first one subscribes to the `Observable` exposed to the template by the component's `quote` property.
|
The first one subscribes to the `Observable` exposed to the template by the component's `quote` property.
|
||||||
|
@ -1963,7 +1960,7 @@ You'll take a different approach with `ActivatedRoute` because
|
||||||
- `paramMap` returns an `Observable` that can emit more than one value
|
- `paramMap` returns an `Observable` that can emit more than one value
|
||||||
during a test.
|
during a test.
|
||||||
- You need the router helper function, `convertToParamMap()`, to create a `ParamMap`.
|
- You need the router helper function, `convertToParamMap()`, to create a `ParamMap`.
|
||||||
- Other _routed components_ tests need a test double for `ActivatedRoute`.
|
- Other _routed component_ tests need a test double for `ActivatedRoute`.
|
||||||
|
|
||||||
These differences argue for a re-usable stub class.
|
These differences argue for a re-usable stub class.
|
||||||
|
|
||||||
|
@ -2763,7 +2760,7 @@ Debug specs in the browser in the same way that you debug an application.
|
||||||
|
|
||||||
1. Reveal the Karma browser window (hidden earlier).
|
1. Reveal the Karma browser window (hidden earlier).
|
||||||
1. Click the **DEBUG** button; it opens a new browser tab and re-runs the tests.
|
1. Click the **DEBUG** button; it opens a new browser tab and re-runs the tests.
|
||||||
1. Open the browser's “Developer Tools” (`Ctrl-Shift-I` on windows; `Command-Option-I` in OSX).
|
1. Open the browser's “Developer Tools” (`Ctrl-Shift-I` on Windows; `Command-Option-I` in macOS).
|
||||||
1. Pick the "sources" section.
|
1. Pick the "sources" section.
|
||||||
1. Open the `1st.spec.ts` test file (Control/Command-P, then start typing the name of the file).
|
1. Open the `1st.spec.ts` test file (Control/Command-P, then start typing the name of the file).
|
||||||
1. Set a breakpoint in the test.
|
1. Set a breakpoint in the test.
|
||||||
|
@ -3259,7 +3256,7 @@ Here are the most useful methods for testers.
|
||||||
Angular can't see that you've changed `personComponent.name` and won't update the `name`
|
Angular can't see that you've changed `personComponent.name` and won't update the `name`
|
||||||
binding until you call `detectChanges`.
|
binding until you call `detectChanges`.
|
||||||
|
|
||||||
Runs `checkNoChanges`afterwards to confirm that there are no circular updates unless
|
Runs `checkNoChanges` afterwards to confirm that there are no circular updates unless
|
||||||
called as `detectChanges(false)`;
|
called as `detectChanges(false)`;
|
||||||
|
|
||||||
</td>
|
</td>
|
||||||
|
|
|
@ -863,7 +863,7 @@ export class Router {
|
||||||
/**
|
/**
|
||||||
* Applies an array of commands to the current URL tree and creates a new URL tree.
|
* Applies an array of commands to the current URL tree and creates a new URL tree.
|
||||||
*
|
*
|
||||||
* When given an activate route, applies the given commands starting from the route.
|
* When given an activated route, applies the given commands starting from the route.
|
||||||
* Otherwise, applies the given command starting from the root.
|
* Otherwise, applies the given command starting from the root.
|
||||||
*
|
*
|
||||||
* @param commands An array of commands to apply.
|
* @param commands An array of commands to apply.
|
||||||
|
|
Loading…
Reference in New Issue