67eac733d2
We should only generate the `providedIn` property in injectable defs if it has a non-null value. `null` does not communicate any information to the runtime that isn't communicated already by the absence of the property. This should give us some modest code size savings. PR Close #34116 |
||
---|---|---|
.. | ||
bazel | ||
bazel-schematics | ||
cli-hello-world | ||
cli-hello-world-ivy-compat | ||
cli-hello-world-ivy-i18n | ||
cli-hello-world-ivy-minimal | ||
cli-hello-world-lazy | ||
cli-hello-world-lazy-rollup | ||
dynamic-compiler | ||
hello_world__closure | ||
hello_world__systemjs_umd | ||
i18n | ||
injectable-def | ||
ivy-i18n | ||
language_service_plugin | ||
ng_elements | ||
ng_update | ||
ng_update_migrations | ||
ngcc | ||
platform-server | ||
service-worker-schema | ||
side-effects | ||
terser | ||
typings_test_ts36 | ||
.gitignore | ||
README.md | ||
_payload-limits.json | ||
check-dependencies.js | ||
get-sharded-tests.js | ||
run_tests.sh |
README.md
Integration tests for Angular
This directory contains end-to-end tests for Angular. Each directory is a self-contained application that exactly mimics how a user might expect Angular to work, so they allow high-fidelity reproductions of real-world issues.
For this to work, we first build the Angular distribution via ./scripts/build-packages-dist.js
, then
install the distribution into each app.
To test Angular CLI applications, we use the cli-hello-world-*
integration tests.
When a significant change is released in the CLI, the applications should be updated with
ng update
:
$ cd integration/cli-hello-world[-*]
$ yarn install
$ yarn ng update @angular/cli @angular-devkit/build-angular
$ yarn build
$ yarn test
Afterwards the @angular/cli
and @angular-devkit/build-angular
should be reverted to the file:../
urls
and the main package.json
should be updated with the new versions.
Render3 tests
The directory cli-hello-world-ivy-compat
contains a test for render3 used with the angular cli.
The cli-hello-world-ivy-minimal
contains a minimal ivy app that is meant to mimic the bazel
equivalent in packages/core/test/bundling/hello_world
, and should be kept similar.
Writing an integration test
The API for each test is:
- Each sub-directory here is an integration test
- Each test should have a
package.json
file - The test runner will run
yarn
andyarn test
on the package
This means that the test should be started by test script, like
"scripts": {"test": "runProgramA && assertResultIsGood"}
Note that the package.json
file uses a special file:../../dist
scheme to reference the Angular
packages, so that the locally-built Angular is installed into the test app.
Also, beware of floating (non-locked) dependencies. If in doubt, you can install the package
directly from file:../../node_modules
.
WARNING
Always ensure that
yarn.lock
files are up-to-date with the correspondingpackage.json
files (wrt the non-local dependencies - i.e. dependencies whose versions do not start withfile:
).You can update a
yarn.lock
file by runningyarn install
in the project subdirectory.
Running integration tests
$ ./integration/run_tests.sh
The test runner will first re-build any stale npm packages, then cd
into each subdirectory to
execute the test.