upstream: Merge remote-tracking branch 'upstream/master' into merge-upstream
# Conflicts: # CHANGELOG.md # aio/content/examples/testing/src/app/app.component.router.spec.ts # aio/content/examples/testing/src/app/dashboard/dashboard-hero.component.spec.ts # aio/content/examples/testing/src/app/dashboard/dashboard.component.spec.ts # aio/content/examples/testing/src/app/hero/hero-detail.component.spec.ts # aio/content/examples/testing/src/app/hero/hero-list.component.spec.ts # aio/content/examples/testing/src/app/twain/twain.component.spec.ts # goldens/public-api/core/testing/testing.d.ts # goldens/size-tracking/aio-payloads.json # package.json # packages/core/test/bundling/forms/bundle.golden_symbols.json # packages/forms/test/form_group_spec.ts
This commit is contained in:
Michael Prentice
@ -124,9 +124,9 @@ Data binding plays an important role in communication between a template and its
|
||||
|
||||
Angular pipes let you declare display-value transformations in your template HTML. A class with the `@Pipe` decorator defines a function that transforms input values to output values for display in a view.
|
||||
|
||||
Angular defines various pipes, such as the [date](https://angular.io/api/common/DatePipe) pipe and [currency](https://angular.io/api/common/CurrencyPipe) pipe; for a complete list, see the [Pipes API list](https://angular.io/api?type=pipe). You can also define new pipes.
|
||||
Angular defines various pipes, such as the [date](api/common/DatePipe) pipe and [currency](api/common/CurrencyPipe) pipe; for a complete list, see the [Pipes API list](api?type=pipe). You can also define new pipes.
|
||||
|
||||
To specify a value transformation in an HTML template, use the [pipe operator (|)](https://angular.io/guide/template-expression-operators#pipe).
|
||||
To specify a value transformation in an HTML template, use the [pipe operator (|)](guide/template-expression-operators#pipe).
|
||||
|
||||
`{{interpolated_value | pipe_name}}`
|
||||
|
||||
|
||||
@ -140,7 +140,7 @@ Angular provides *value accessors* for all of the basic HTML form elements and t
|
||||
|
||||
You can't apply `[(ngModel)]` to a non-form native element or a
|
||||
third-party custom component until you write a suitable value accessor. For more information, see
|
||||
the API documentation on [DefaultValueAccessor](https://angular.io/api/forms/DefaultValueAccessor).
|
||||
the API documentation on [DefaultValueAccessor](api/forms/DefaultValueAccessor).
|
||||
|
||||
You don't need a value accessor for an Angular component that
|
||||
you write because you can name the value and event properties
|
||||
|
||||
@ -42,11 +42,11 @@ For example, your `myBuilder` folder could contain the following files.
|
||||
| `src/my-builder.ts` | Main source file for the builder definition. |
|
||||
| `src/my-builder.spec.ts` | Source file for tests. |
|
||||
| `src/schema.json` | Definition of builder input options. |
|
||||
| `builders.json` | Testing configuration. |
|
||||
| `builders.json` | Builders definition. |
|
||||
| `package.json` | Dependencies. See https://docs.npmjs.com/files/package.json. |
|
||||
| `tsconfig.json` | [TypeScript configuration](https://www.typescriptlang.org/docs/handbook/tsconfig-json.html). |
|
||||
|
||||
You can publish the builder to `npm` (see [Publishing your Library](https://angular.io/guide/creating-libraries#publishing-your-library)). If you publish it as `@example/my-builder`, you can install it using the following command.
|
||||
You can publish the builder to `npm` (see [Publishing your Library](guide/creating-libraries#publishing-your-library)). If you publish it as `@example/my-builder`, you can install it using the following command.
|
||||
|
||||
<code-example language="sh">
|
||||
|
||||
|
||||
@ -58,6 +58,7 @@ v9 - v12
|
||||
| `@angular/core` | [`ANALYZE_FOR_ENTRY_COMPONENTS`](api/core/ANALYZE_FOR_ENTRY_COMPONENTS) | <!--v9--> v11 |
|
||||
| `@angular/router` | [`loadChildren` string syntax](#loadChildren) | <!--v9--> v11 |
|
||||
| `@angular/core/testing` | [`TestBed.get`](#testing) | <!--v9--> v12 |
|
||||
| `@angular/core/testing` | [`async`](#testing) | <!--v9--> v12 |
|
||||
| `@angular/router` | [`ActivatedRoute` params and `queryParams` properties](#activatedroute-props) | unspecified |
|
||||
| template syntax | [`/deep/`, `>>>`, and `::ng-deep`](#deep-component-style-selector) | <!--v7--> unspecified |
|
||||
| browser support | [`IE 9 and 10, IE mobile`](#ie-9-10-and-mobile) | <!--v10--> v11 |
|
||||
@ -108,6 +109,7 @@ Tip: In the [API reference section](api) of this doc site, deprecated APIs are i
|
||||
| API | Replacement | Deprecation announced | Notes |
|
||||
| --- | ----------- | --------------------- | ----- |
|
||||
| [`TestBed.get`](api/core/testing/TestBed#get) | [`TestBed.inject`](api/core/testing/TestBed#inject) | v9 | Same behavior, but type safe. |
|
||||
| [`async`](api/core/testing/async) | [`waitForAsync`](api/core/testing/waitForAsync) | v10 | Same behavior, but rename to avoid confusion. |
|
||||
|
||||
|
||||
{@a forms}
|
||||
@ -477,7 +479,7 @@ The final decision was made on three key points:
|
||||
|
||||
|
||||
{@a wrapped-value}
|
||||
### `WrappedValue`
|
||||
### `WrappedValue`
|
||||
|
||||
The purpose of `WrappedValue` is to allow the same object instance to be treated as different for the purposes of change detection.
|
||||
It is commonly used with the `async` pipe in the case where the `Observable` produces the same instance of the value.
|
||||
@ -487,7 +489,7 @@ No replacement is planned for this deprecation.
|
||||
|
||||
If you rely on the behavior that the same object instance should cause change detection, you have two options:
|
||||
- Clone the resulting value so that it has a new identity.
|
||||
- Explicitly call [`ChangeDetectorRef.detectChanges()`](api/core/ChangeDetectorRef#detectchanges) to force the update.
|
||||
- Explicitly call [`ChangeDetectorRef.detectChanges()`](api/core/ChangeDetectorRef#detectchanges) to force the update.
|
||||
|
||||
{@a deprecated-cli-flags}
|
||||
## Deprecated CLI APIs and Options
|
||||
|
||||
@ -867,7 +867,7 @@ To learn more, see [Introduction to Services and Dependency Injection](guide/arc
|
||||
|
||||
## structural directives
|
||||
|
||||
A category of [directive](#directive) that is responsible for shaping HTML layout by modifying the DOM&mdashthat is, adding, removing, or manipulating elements and their children.
|
||||
A category of [directive](#directive) that is responsible for shaping HTML layout by modifying the DOM—that is, adding, removing, or manipulating elements and their children.
|
||||
|
||||
To learn more, see [Structural Directives](guide/structural-directives).
|
||||
|
||||
|
||||
@ -58,7 +58,7 @@ While following these steps, you can [explore the translated example app](#app-p
|
||||
|
||||
The following are optional practices that may be required in special cases:
|
||||
|
||||
* [Set the source locale manually](#set-source-manually) if you need to set the [LOCALE_ID](https://angular.io/api/core/LOCALE_ID "API reference for LOCALE_ID") token.
|
||||
* [Set the source locale manually](#set-source-manually) if you need to set the [LOCALE_ID](api/core/LOCALE_ID "API reference for LOCALE_ID") token.
|
||||
* [Import global variants of the locale data](#import-locale) for extra locale data.
|
||||
* [Manage marked text with custom IDs](#custom-id) if you require more control over matching translations.
|
||||
|
||||
@ -77,7 +77,7 @@ This command updates your project's `package.json` and `polyfills.ts` files to i
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
For more information about `package.json` and polyfill packages, see [Workspace npm dependencies](https://angular.io/guide/npm-packages).
|
||||
For more information about `package.json` and polyfill packages, see [Workspace npm dependencies](guide/npm-packages).
|
||||
|
||||
</div>
|
||||
|
||||
@ -804,7 +804,7 @@ The following tabs show the example app and its translation files:
|
||||
|
||||
The following are optional practices that may be required in special cases:
|
||||
|
||||
* [Set the source locale manually](#set-source-manually) by setting the [LOCALE_ID](https://angular.io/api/core/LOCALE_ID "API reference for LOCALE_ID") token.
|
||||
* [Set the source locale manually](#set-source-manually) by setting the [LOCALE_ID](api/core/LOCALE_ID "API reference for LOCALE_ID") token.
|
||||
* [Import global variants of the locale data](#import-locale) for extra locale data.
|
||||
* [Manage marked text with custom IDs](#custom-id) if you require more control over matching translations.
|
||||
|
||||
|
||||
93
aio/content/guide/roadmap.md
Normal file
93
aio/content/guide/roadmap.md
Normal file
@ -0,0 +1,93 @@
|
||||
# Angular Roadmap
|
||||
|
||||
Angular receives a large number of feature requests, both from inside Google and from the broader open-source community. At the same time, our list of projects contains plenty of maintenance tasks, code refactorings, potential performance improvements, and so on. We bring together representatives from developer relations, product management, and engineering to prioritize this list. As new projects come into the queue, we regularly position them based on relative priority to other projects. As work gets done, projects will move up in the queue.
|
||||
|
||||
The projects below are not associated with a particular Angular version. We'll release them on completion, and they will be part of a specific version based on our release schedule, following semantic versioning. For example, features are released in the next minor after they are complete, or the next major if they include breaking changes.
|
||||
|
||||
## In Progress
|
||||
|
||||
### Operation Bye Bye Backlog (aka Operation Byelog)
|
||||
|
||||
We are actively investing up to 50% of our engineering capacity on triaging issues and PRs until we have a clear understanding of broader community needs. After that, we'll commit up to 20% of our engineering capacity to keep up with new submissions promptly.
|
||||
|
||||
### Support TypeScript 4.0
|
||||
|
||||
We're working on adding support for TypeScript 4.0 ahead of its stable release. We always want Angular to stay up-to-date with the latest version of TypeScript so that developers get the best the language has to offer.
|
||||
|
||||
### Update our e2e testing strategy
|
||||
|
||||
To ensure we provide a future-proof e2e testing strategy, we want to evaluate the state of Protractor, community innovations, e2e best practices, and explore novel opportunities.
|
||||
|
||||
### Angular libraries use Ivy
|
||||
|
||||
We are investing in the design and development of Ivy library distribution plan, which will include an update of the library package format to use Ivy compilation, unblock the deprecation of the View Engine library format, and [ngcc](guide/glossary#ngcc).
|
||||
|
||||
### Evaluate future RxJS changes (v7 and beyond)
|
||||
|
||||
We want to ensure Angular developers are taking advantage of the latest capabilities of RxJS and have a smooth transition to the next major releases of the framework. For this purpose, we will explore and document the scope of the changes in v7 and beyond of RxJS and plan an update strategy.
|
||||
|
||||
### Angular language service uses Ivy
|
||||
|
||||
Today the language service still uses the View Engine compiler and type checking, even for Ivy applications. We want to use the Ivy template parser and improved type checking for the Angular Language service to match application behavior. This migration will also be a step towards unblocking the removal of View Engine, which will simplify Angular, reduce the npm package size, and improve the framework's maintainability.
|
||||
|
||||
### Expand component harnesses best practices
|
||||
|
||||
Angular CDK introduced the concept of [component test harnesses](https://material.angular.io/cdk/test-harnesses) to Angular in version 9. Test harnesses allow component authors to create supported APIs for testing component interactions. We're continuing to improve this harness infrastructure and clarifying the best practices around using harnesses. We're also working to drive more harness adoption inside of Google.
|
||||
|
||||
### Support native [Trusted Types](https://web.dev/trusted-types/) in Angular
|
||||
|
||||
In collaboration with Google's security team, we're adding support for the new Trusted Types API. This web platform API will help developers build more secure web applications.
|
||||
|
||||
### Integrate [MDC Web](https://material.io/develop/web/) into Angular Material
|
||||
|
||||
MDC Web is a library created by Google's Material Design team that provides reusable primitives for building Material Design components. The Angular team is incorporating these primitives into Angular Material. Using MDC Web will align Angular Material more closely with the Material Design specification, expand accessibility, overall improve component quality, and improve our team's velocity.
|
||||
|
||||
### Offer Google engineers better integration with Angular and Google's internal server stack
|
||||
|
||||
This is an internal project to add support for Angular front-ends to Google's internal integrated server stack.
|
||||
|
||||
### Angular versioning & branching
|
||||
|
||||
We want to consolidate release management tooling between Angular's multiple GitHub repositories ([angular/angular](https://github.com/angular/angular), [angular/angular-cli](https://github.com/angular/angular-cli), and [angular/components](https://github.com/angular/components)). This effort will allow us to reuse infrastructure, unify and simplify processes, and improve our release process's reliability.
|
||||
|
||||
## Future
|
||||
|
||||
### Refresh introductory documentation
|
||||
|
||||
We will redefine the user learning journeys and refresh the introductory documentation. We will clearly state the benefits of Angular, how to explore its capabilities, and provide guidance so developers can become proficient with the framework in as little time as possible.
|
||||
|
||||
### Strict typing for `@angular/forms`
|
||||
|
||||
We will work on implementing stricter type checking for reactive forms. This way, we will allow developers to catch more issues during development time, enable better text editor and IDE support, and improve the type checking for reactive forms.
|
||||
|
||||
### webpack 5 in the Angular CLI
|
||||
|
||||
Webpack 5 brings a lot of build speed and bundle size improvements. To make them available for Angular developers, we will invest in migrating Angular CLI from using deprecated and removed webpack APIs.
|
||||
|
||||
### Commit message standardization
|
||||
|
||||
We want to unify commit message requirements and conformance across Angular repositories ([angular/angular](https://github.com/angular/angular), [angular/components](https://github.com/angular/components), [angular/angular-cli](https://github.com/angular/angular-cli)) to bring consistency to our development process and reuse infrastructure tooling.
|
||||
|
||||
### Optional Zone.js
|
||||
|
||||
We are going to design and implement a plan to make Zone.js optional from Angular applications. This way, we will simplify the framework, improve debugging, and reduce application bundle size. Additionally, this will allow us to take advantage of native async/await syntax, which currently Zone.js does not support.
|
||||
|
||||
### Remove legacy [View Engine](guide/ivy)
|
||||
|
||||
After the transition of all our internal tooling to Ivy has completed, we want to remove the legacy View Engine for smaller Angular conceptual overhead, smaller package size, lower maintenance cost, and lower complexity of the codebase.
|
||||
|
||||
### Angular DevTools
|
||||
|
||||
We’ll be working on development tooling for Angular that will provide utilities for debugging and performance profiling. This project aims to help developers understand the component structure and the change detection in an Angular application.
|
||||
|
||||
### Optional NgModules
|
||||
|
||||
To simplify the Angular mental model and learning journey, we’ll be working on making NgModules optional. This work will allow developers to develop standalone components and implement an alternative API for declaring the component’s compilation scope.
|
||||
|
||||
### Ergonomic component level code-splitting APIs
|
||||
|
||||
A common problem of web applications is their slow initial load time. A way to improve it is to apply more granular code-splitting on a component level. To encourage this practice, we’ll be working on more ergonomic code-splitting APIs.
|
||||
|
||||
### Migration to ESLint
|
||||
|
||||
With the deprecation of TSLint we will be moving to ESLint. As part of the process, we will work on ensuring backward compatibility with our current recommended TSLint configuration, implement a migration strategy for existing Angular applications and introduce new tooling to the Angular CLI toolchain.
|
||||
@ -53,14 +53,27 @@ This field contains an array of asset groups, each of which defines a set of ass
|
||||
|
||||
```json
|
||||
{
|
||||
"assetGroups": [{
|
||||
...
|
||||
}, {
|
||||
...
|
||||
}]
|
||||
"assetGroups": [
|
||||
{
|
||||
...
|
||||
},
|
||||
{
|
||||
...
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
When the ServiceWorker handles a request, it checks asset groups in the order in which they appear in `ngsw-config.json`.
|
||||
The first asset group that matches the requested resource handles the request.
|
||||
|
||||
It is recommended that you put the more specific asset groups higher in the list.
|
||||
For example, an asset group that matches `/foo.js` should appear before one that matches `*.js`.
|
||||
|
||||
</div>
|
||||
|
||||
Each asset group specifies both a group of resources and a policy that governs them. This policy determines when the resources are fetched and what happens when changes are detected.
|
||||
|
||||
Asset groups follow the Typescript interface shown here:
|
||||
@ -123,6 +136,31 @@ These options are used to modify the matching behavior of requests. They are pas
|
||||
|
||||
Unlike asset resources, data requests are not versioned along with the app. They're cached according to manually-configured policies that are more useful for situations such as API requests and other data dependencies.
|
||||
|
||||
This field contains an array of data groups, each of which defines a set of data resources and the policy by which they are cached.
|
||||
|
||||
```json
|
||||
{
|
||||
"dataGroups": [
|
||||
{
|
||||
...
|
||||
},
|
||||
{
|
||||
...
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
When the ServiceWorker handles a request, it checks data groups in the order in which they appear in `ngsw-config.json`.
|
||||
The first data group that matches the requested resource handles the request.
|
||||
|
||||
It is recommended that you put the more specific data groups higher in the list.
|
||||
For example, a data group that matches `/api/foo.json` should appear before one that matches `/api/*.json`.
|
||||
|
||||
</div>
|
||||
|
||||
Data groups follow this Typescript interface:
|
||||
|
||||
```typescript
|
||||
|
||||
@ -159,10 +159,10 @@ It also generates an initial test file for the component, `banner-external.compo
|
||||
<div class="alert is-helpful">
|
||||
|
||||
Because `compileComponents` is asynchronous, it uses
|
||||
the [`async`](api/core/testing/async) utility
|
||||
the [`waitForAsync`](api/core/testing/waitForAsync) utility
|
||||
function imported from `@angular/core/testing`.
|
||||
|
||||
Please refer to the [async](guide/testing-components-scenarios#async) section for more details.
|
||||
Please refer to the [waitForAsync](guide/testing-components-scenarios#waitForAsync) section for more details.
|
||||
|
||||
</div>
|
||||
|
||||
|
||||
@ -402,7 +402,7 @@ There is no nested syntax (like a `Promise.then()`) to disrupt the flow of contr
|
||||
<div class="alert is-helpful">
|
||||
|
||||
Limitation: The `fakeAsync()` function won't work if the test body makes an `XMLHttpRequest` (XHR) call.
|
||||
XHR calls within a test are rare, but if you need to call XHR, see [`async()`](#async), below.
|
||||
XHR calls within a test are rare, but if you need to call XHR, see [`waitForAsync()`](#waitForAsync), below.
|
||||
|
||||
</div>
|
||||
|
||||
@ -587,41 +587,41 @@ Then call `detectChanges()` to tell Angular to update the screen.
|
||||
|
||||
Then you can assert that the quote element displays the expected text.
|
||||
|
||||
{@a async}
|
||||
{@a waitForAsync}
|
||||
|
||||
#### Async test with _async()_
|
||||
#### Async test with _waitForAsync()_
|
||||
|
||||
To use `async()` functionality, you must import `zone.js/dist/zone-testing` in your test setup file.
|
||||
To use `waitForAsync()` functionality, you must import `zone.js/dist/zone-testing` in your test setup file.
|
||||
If you created your project with the Angular CLI, `zone-testing` is already imported in `src/test.ts`.
|
||||
|
||||
The `fakeAsync()` utility function has a few limitations.
|
||||
In particular, it won't work if the test body makes an `XMLHttpRequest` (XHR) call.
|
||||
XHR calls within a test are rare so you can generally stick with [`fakeAsync()`](#fake-async).
|
||||
But if you ever do need to call `XMLHttpRequest`, you'll want to know about `async()`.
|
||||
But if you ever do need to call `XMLHttpRequest`, you'll want to know about `waitForAsync()`.
|
||||
|
||||
<div class="alert is-helpful">
|
||||
|
||||
The `TestBed.compileComponents()` method (see [below](#compile-components)) calls `XHR`
|
||||
to read external template and css files during "just-in-time" compilation.
|
||||
Write tests that call `compileComponents()` with the `async()` utility.
|
||||
Write tests that call `compileComponents()` with the `waitForAsync()` utility.
|
||||
|
||||
</div>
|
||||
|
||||
Here's the previous `fakeAsync()` test, re-written with the `async()` utility.
|
||||
Here's the previous `fakeAsync()` test, re-written with the `waitForAsync()` utility.
|
||||
|
||||
<code-example
|
||||
path="testing/src/app/twain/twain.component.spec.ts"
|
||||
region="async-test">
|
||||
</code-example>
|
||||
|
||||
The `async()` utility hides some asynchronous boilerplate by arranging for the tester's code
|
||||
The `waitForAsync()` utility hides some asynchronous boilerplate by arranging for the tester's code
|
||||
to run in a special _async test zone_.
|
||||
You don't need to pass Jasmine's `done()` into the test and call `done()` because it is `undefined` in promise or observable callbacks.
|
||||
|
||||
But the test's asynchronous nature is revealed by the call to `fixture.whenStable()`,
|
||||
which breaks the linear flow of control.
|
||||
|
||||
When using an `intervalTimer()` such as `setInterval()` in `async()`, remember to cancel the timer with `clearInterval()` after the test, otherwise the `async()` never ends.
|
||||
When using an `intervalTimer()` such as `setInterval()` in `waitForAsync()`, remember to cancel the timer with `clearInterval()` after the test, otherwise the `waitForAsync()` never ends.
|
||||
|
||||
{@a when-stable}
|
||||
|
||||
@ -641,18 +641,18 @@ update the quote element with the expected text.
|
||||
|
||||
#### Jasmine _done()_
|
||||
|
||||
While the `async()` and `fakeAsync()` functions greatly
|
||||
While the `waitForAsync()` and `fakeAsync()` functions greatly
|
||||
simplify Angular asynchronous testing,
|
||||
you can still fall back to the traditional technique
|
||||
and pass `it` a function that takes a
|
||||
[`done` callback](https://jasmine.github.io/2.0/introduction.html#section-Asynchronous_Support).
|
||||
|
||||
You can't call `done()` in `async()` or `fakeAsync()` functions, because the `done parameter`
|
||||
You can't call `done()` in `waitForAsync()` or `fakeAsync()` functions, because the `done parameter`
|
||||
is `undefined`.
|
||||
|
||||
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()`, but it is occasionally necessary when code involves the `intervalTimer()` like `setInterval`.
|
||||
Writing test functions with `done()`, is more cumbersome than `waitForAsync()`and `fakeAsync()`, but it is occasionally necessary when code involves the `intervalTimer()` like `setInterval`.
|
||||
|
||||
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.
|
||||
@ -738,7 +738,7 @@ you tell the `TestScheduler` to _flush_ its queue of prepared tasks like this.
|
||||
region="test-scheduler-flush"></code-example>
|
||||
|
||||
This step serves a purpose analogous to [tick()](api/core/testing/tick) and `whenStable()` in the
|
||||
earlier `fakeAsync()` and `async()` examples.
|
||||
earlier `fakeAsync()` and `waitForAsync()` examples.
|
||||
The balance of the test is the same as those examples.
|
||||
|
||||
#### Marble error testing
|
||||
@ -1535,7 +1535,7 @@ You must call `compileComponents()` within an asynchronous test function.
|
||||
<div class="alert is-critical">
|
||||
|
||||
If you neglect to make the test function async
|
||||
(e.g., forget to use `async()` as described below),
|
||||
(e.g., forget to use `waitForAsync()` as described below),
|
||||
you'll see this error message
|
||||
|
||||
<code-example language="sh" class="code-shell" hideCopy>
|
||||
@ -1549,7 +1549,7 @@ A typical approach is to divide the setup logic into two separate `beforeEach()`
|
||||
1. An async `beforeEach()` that compiles the components
|
||||
1. A synchronous `beforeEach()` that performs the remaining setup.
|
||||
|
||||
To follow this pattern, import the `async()` helper with the other testing symbols.
|
||||
To follow this pattern, import the `waitForAsync()` helper with the other testing symbols.
|
||||
|
||||
<code-example
|
||||
path="testing/src/app/banner/banner-external.component.spec.ts"
|
||||
@ -1565,7 +1565,7 @@ Write the first async `beforeEach` like this.
|
||||
region="async-before-each"
|
||||
header="app/banner/banner-external.component.spec.ts (async beforeEach)"></code-example>
|
||||
|
||||
The `async()` helper function takes a parameterless function with the body of the setup.
|
||||
The `waitForAsync()` helper function takes a parameterless function with the body of the setup.
|
||||
|
||||
The `TestBed.configureTestingModule()` method returns the `TestBed` class so you can chain
|
||||
calls to other `TestBed` static methods such as `compileComponents()`.
|
||||
|
||||
@ -25,7 +25,7 @@ Here's a summary of the stand-alone functions, in order of likely utility:
|
||||
<td>
|
||||
|
||||
Runs the body of a test (`it`) or setup (`beforeEach`) function within a special _async test zone_.
|
||||
See [discussion above](guide/testing-components-scenarios#async).
|
||||
See [discussion above](guide/testing-components-scenarios#waitForAsync).
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
|
||||
@ -306,9 +306,9 @@ If you develop angular locally with `ng serve`, a `websocket` connection is set
|
||||
In Windows, by default, one application can only have 6 websocket connections, <a href="https://msdn.microsoft.com/library/ee330736%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396#websocket_maxconn" title="MSDN WebSocket settings">MSDN WebSocket Settings</a>.
|
||||
So when IE is refreshed (manually or automatically by `ng serve`), sometimes the websocket does not close properly. When websocket connections exceed the limitations, a `SecurityError` will be thrown. This error will not affect the angular application, you can just restart IE to clear this error, or modify the windows registry to update the limitations.
|
||||
|
||||
## Appendix: Test using `fakeAsync()/async()`
|
||||
## Appendix: Test using `fakeAsync()/waitForAsync()`
|
||||
|
||||
If you use the `fakeAsync()/async()` helper function to run unit tests (for details, read the [Testing guide](guide/testing-components-scenarios#fake-async)), you need to import `zone.js/dist/zone-testing` in your test setup file.
|
||||
If you use the `fakeAsync()/waitForAsync()` helper function to run unit tests (for details, read the [Testing guide](guide/testing-components-scenarios#fake-async)), you need to import `zone.js/dist/zone-testing` in your test setup file.
|
||||
|
||||
<div class="alert is-important">
|
||||
If you create project with `Angular/CLI`, it is already imported in `src/test.ts`.
|
||||
|
||||
Reference in New Issue
Block a user