angular-cn/integration
Pete Bacon Darwin f640a4a494 fix(ivy): i18n - turn on legacy message-id support by default (#33053)
For v9 we want the migration to the new i18n to be as
simple as possible.

Previously the developer had to positively choose to use
legacy messsage id support in the case that their translation
files had not been migrated to the new format by setting the
`legacyMessageIdFormat` option in tsconfig.json to the format
of their translation files.

Now this setting has been changed to `enableI18nLegacyMessageFormat`
as is a boolean that defaults to `true`. The format is then read from
the `i18nInFormat` option, which was previously used to trigger translations
in the pre-ivy angular compiler.

PR Close #33053
2019-10-10 13:58:30 -07:00
..
bazel build: add missing http-server dep to bazel example (#32889) 2019-10-08 09:27:11 -07:00
bazel-schematics
cli-hello-world refactor: rename unpatched event flag in Zone from `BLACK_LISTED_EVENTS` to `UNPATCHED_EVENTS` (#29617) 2019-10-04 08:44:58 -07:00
cli-hello-world-ivy-compat feat(ngcc): expose `--create-ivy-entry-points` option on ivy-ngcc (#33049) 2019-10-09 13:16:16 -07:00
cli-hello-world-ivy-i18n fix(ivy): i18n - turn on legacy message-id support by default (#33053) 2019-10-10 13:58:30 -07:00
cli-hello-world-ivy-minimal refactor: rename unpatched event flag in Zone from `BLACK_LISTED_EVENTS` to `UNPATCHED_EVENTS` (#29617) 2019-10-04 08:44:58 -07:00
dynamic-compiler
hello_world__closure
hello_world__systemjs_umd
i18n
injectable-def
language_service_plugin
ng_elements
ng_update
ng_update_migrations
ngcc
platform-server
service-worker-schema
side-effects
terser
typings_test_ts34
typings_test_ts35
.gitignore test(ivy): i18n - add compile time translation to integration test (#32881) 2019-10-09 13:19:38 -07:00
README.md
_payload-limits.json refactor(core): remove deprecated Renderer (#33019) 2019-10-08 09:23:00 -07:00
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 just like we would publish it to npm, then install the distribution into each app.

To test Angular CLI applications, we use the integration test cli-hello-world. When a significant change is released in the CLI, the application 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
# typescript version

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 and yarn 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.

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.