honeymoose
/
angular-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
angular-cn/packages/core/test/acceptance/BUILD.bazel

54 lines
1.4 KiB
Python
Raw Normal View History

test(ivy): move some local ref tests to use TestBed infrastructure. (#28534) When we first started writing tests for Ivy, we did not yet have a compatible compiler. For this reason, we set up the Ivy runtime tests to run with generated code that we wrote by hand (instead of real code generated by the compiler). Now that we have a working Ivy compiler and TestBed infrastructure that is compatible with Ivy, we should start writing integration tests that leverage them (no more handwritten generated code!). This will prevent bugs where the compiler code and runtime code become out of sync (which is easy if they are tested separately). And eventually, we should migrate all the existing runtime tests in "core/test/render3" to TestBed and ngtsc. To kick off this effort, this commit migrates some existing tests from "core/test/render3/exports_spec.ts" and saves them in a new file with the same name in the "core/test/acceptance" folder. PR Close #28534
2019-02-04 23:42:30 -05:00
package(default_visibility = ["//visibility:private"])
test(ivy): move render3 renderer_factory tests to acceptance (#30435) Moves all manual render3 tests which are located within the `renderer_factory_spec.ts` file to acceptance tests. A few tests that use Ivy-specific logic which is not replicable with `TestBed` remain in the render3 folder (e.g. using `renderTemplate`) Additionally migrated tests that assert the lifecycles of the renderer_factory are set to *ivy only* as the lifecycle seems to be different in Ivy. Tracked with: FW-1320 PR Close #30435
2019-05-13 13:01:55 -04:00
load("//tools:defaults.bzl", "jasmine_node_test", "ts_library", "ts_web_test_suite")
test(ivy): move some local ref tests to use TestBed infrastructure. (#28534) When we first started writing tests for Ivy, we did not yet have a compatible compiler. For this reason, we set up the Ivy runtime tests to run with generated code that we wrote by hand (instead of real code generated by the compiler). Now that we have a working Ivy compiler and TestBed infrastructure that is compatible with Ivy, we should start writing integration tests that leverage them (no more handwritten generated code!). This will prevent bugs where the compiler code and runtime code become out of sync (which is easy if they are tested separately). And eventually, we should migrate all the existing runtime tests in "core/test/render3" to TestBed and ngtsc. To kick off this effort, this commit migrates some existing tests from "core/test/render3/exports_spec.ts" and saves them in a new file with the same name in the "core/test/acceptance" folder. PR Close #28534
2019-02-04 23:42:30 -05:00
ts_library(
name = "acceptance_lib",
testonly = True,
srcs = glob(
["**/*.ts"],
),
deps = [
test(ivy): move render3 renderer_factory tests to acceptance (#30435) Moves all manual render3 tests which are located within the `renderer_factory_spec.ts` file to acceptance tests. A few tests that use Ivy-specific logic which is not replicable with `TestBed` remain in the render3 folder (e.g. using `renderTemplate`) Additionally migrated tests that assert the lifecycles of the renderer_factory are set to *ivy only* as the lifecycle seems to be different in Ivy. Tracked with: FW-1320 PR Close #30435
2019-05-13 13:01:55 -04:00
"//packages/animations",
"//packages/animations/browser",
"//packages/animations/browser/testing",
test(ivy): move some local ref tests to use TestBed infrastructure. (#28534) When we first started writing tests for Ivy, we did not yet have a compatible compiler. For this reason, we set up the Ivy runtime tests to run with generated code that we wrote by hand (instead of real code generated by the compiler). Now that we have a working Ivy compiler and TestBed infrastructure that is compatible with Ivy, we should start writing integration tests that leverage them (no more handwritten generated code!). This will prevent bugs where the compiler code and runtime code become out of sync (which is easy if they are tested separately). And eventually, we should migrate all the existing runtime tests in "core/test/render3" to TestBed and ngtsc. To kick off this effort, this commit migrates some existing tests from "core/test/render3/exports_spec.ts" and saves them in a new file with the same name in the "core/test/acceptance" folder. PR Close #28534
2019-02-04 23:42:30 -05:00
"//packages/common",
feat(ivy): use i18n locale data to determine the plural form of ICU expressions (#29249) Plural ICU expressions depend on the locale (different languages have different plural forms). Until now the locale was hard coded as `en-US`. For compatibility reasons, if you use ivy with AOT and bootstrap your app with `bootstrapModule` then the `LOCALE_ID` token will be set automatically for ivy, which is then used to get the correct plural form. If you use JIT, you need to define the `LOCALE_ID` provider on the module that you bootstrap. For `TestBed` you can use either `configureTestingModule` or `overrideProvider` to define that provider. If you don't use the compat mode and start your app with `renderComponent` you need to call `ɵsetLocaleId` manually to define the `LOCALE_ID` before bootstrap. We expect this to change once we start adding the new i18n APIs, so don't rely on this function (there's a reason why it's a private export). PR Close #29249
2019-05-17 10:13:31 -04:00
"//packages/common/locales",
test(ivy): move some local ref tests to use TestBed infrastructure. (#28534) When we first started writing tests for Ivy, we did not yet have a compatible compiler. For this reason, we set up the Ivy runtime tests to run with generated code that we wrote by hand (instead of real code generated by the compiler). Now that we have a working Ivy compiler and TestBed infrastructure that is compatible with Ivy, we should start writing integration tests that leverage them (no more handwritten generated code!). This will prevent bugs where the compiler code and runtime code become out of sync (which is easy if they are tested separately). And eventually, we should migrate all the existing runtime tests in "core/test/render3" to TestBed and ngtsc. To kick off this effort, this commit migrates some existing tests from "core/test/render3/exports_spec.ts" and saves them in a new file with the same name in the "core/test/acceptance" folder. PR Close #28534
2019-02-04 23:42:30 -05:00
"//packages/compiler",
"//packages/compiler/testing",
"//packages/core",
test(ivy): add onlyInIvy perf counter expectations (#30339) We have an issue where we would like to be able to test perf counter metrics in acceptance tests, but we are unable to do so, because it will break when those same tests are run with ViewEngine. This PR adds a testing utility to `onlyInIvy` that allows for testing of performance counters, and even gives readable errors for what value on `ngDevMode` is incorrect. Has typings for decent autocompletion as well. PR Close #30339
2019-05-08 16:14:42 -04:00
"//packages/core/src/util",
test(ivy): move some local ref tests to use TestBed infrastructure. (#28534) When we first started writing tests for Ivy, we did not yet have a compatible compiler. For this reason, we set up the Ivy runtime tests to run with generated code that we wrote by hand (instead of real code generated by the compiler). Now that we have a working Ivy compiler and TestBed infrastructure that is compatible with Ivy, we should start writing integration tests that leverage them (no more handwritten generated code!). This will prevent bugs where the compiler code and runtime code become out of sync (which is easy if they are tested separately). And eventually, we should migrate all the existing runtime tests in "core/test/render3" to TestBed and ngtsc. To kick off this effort, this commit migrates some existing tests from "core/test/render3/exports_spec.ts" and saves them in a new file with the same name in the "core/test/acceptance" folder. PR Close #28534
2019-02-04 23:42:30 -05:00
"//packages/core/testing",
refactor(ivy): remove `i18nConfigureLocalize` instruction (#31609) This has been replaced by the `loadTranslations()` function in `@angular/localize/run_time`. PR Close #31609
2019-08-08 17:05:43 -04:00
"//packages/localize",
feat(ivy): i18n - reorganize entry-points for better reuse (#32488) This is a refactoring that moves the source code around to provide a better platform for adding the compile-time inlining. 1. Move the global side-effect import from the primary entry-point to a secondary entry-point @angular/localize/init. This has two benefits: first it allows the top level entry-point to contain tree-shakable shareable code; second it gives the side-effect import more of an "action" oriented name, which indicates that importing it does something tangible 2. Move all the source code into the top src folder, and import the localize related functions into the localize/init/index.ts entry-point. This allows the different parts of the package to share code without a proliferation of secondary entry-points (i.e. localize/utils). 3. Avoid publicly exporting any utilities at this time - the only public API at this point are the global `$localize` function and the two runtime helpers `loadTranslations()` and `clearTranslations()`. This does not mean that we will not expose additional helpers for 3rd party tooling in the future, but it avoid us preemptively exposing something that we might want to change in the near future. Notes: It is not possible to have the `$localize` code in the same Bazel package as the rest of the code. If we did this, then the bundled `@angular/localize/init` entry-point code contains all of the helper code, even though most of it is not used. Equally it is not possible to have the `$localize` types (i.e. `LocalizeFn` and `TranslateFn`) defined in the `@angular/localize/init` entry-point because these types are needed for the runtime code, which is inside the primary entry-point. Importing them from `@angular/localize/init` would run the side-effect. The solution is to have a Bazel sub-package at `//packages/localize/src/localize` which contains these types and the `$localize` function implementation. The primary `//packages/localize` entry-point imports the types without any side-effect. The secondary `//packages/localize/init` entry-point imports the `$localize` function and attaches it to the global scope as a side-effect, without bringing with it all the other utility functions. BREAKING CHANGES: The entry-points have changed: * To attach the `$localize` function to the global scope import from `@angular/localize/init`. Previously it was `@angular/localize`. * To access the `loadTranslations()` and `clearTranslations()` functions, import from `@angular/localize`. Previously it was `@angular/localize/run_time`. PR Close #32488
2019-08-10 07:51:30 -04:00
"//packages/localize/init",
test(ivy): move some local ref tests to use TestBed infrastructure. (#28534) When we first started writing tests for Ivy, we did not yet have a compatible compiler. For this reason, we set up the Ivy runtime tests to run with generated code that we wrote by hand (instead of real code generated by the compiler). Now that we have a working Ivy compiler and TestBed infrastructure that is compatible with Ivy, we should start writing integration tests that leverage them (no more handwritten generated code!). This will prevent bugs where the compiler code and runtime code become out of sync (which is easy if they are tested separately). And eventually, we should migrate all the existing runtime tests in "core/test/render3" to TestBed and ngtsc. To kick off this effort, this commit migrates some existing tests from "core/test/render3/exports_spec.ts" and saves them in a new file with the same name in the "core/test/acceptance" folder. PR Close #28534
2019-02-04 23:42:30 -05:00
"//packages/platform-browser",
"//packages/platform-browser-dynamic",
test(ivy): move render3 renderer_factory tests to acceptance (#30435) Moves all manual render3 tests which are located within the `renderer_factory_spec.ts` file to acceptance tests. A few tests that use Ivy-specific logic which is not replicable with `TestBed` remain in the render3 folder (e.g. using `renderTemplate`) Additionally migrated tests that assert the lifecycles of the renderer_factory are set to *ivy only* as the lifecycle seems to be different in Ivy. Tracked with: FW-1320 PR Close #30435
2019-05-13 13:01:55 -04:00
"//packages/platform-browser/animations",
test(ivy): move some local ref tests to use TestBed infrastructure. (#28534) When we first started writing tests for Ivy, we did not yet have a compatible compiler. For this reason, we set up the Ivy runtime tests to run with generated code that we wrote by hand (instead of real code generated by the compiler). Now that we have a working Ivy compiler and TestBed infrastructure that is compatible with Ivy, we should start writing integration tests that leverage them (no more handwritten generated code!). This will prevent bugs where the compiler code and runtime code become out of sync (which is easy if they are tested separately). And eventually, we should migrate all the existing runtime tests in "core/test/render3" to TestBed and ngtsc. To kick off this effort, this commit migrates some existing tests from "core/test/render3/exports_spec.ts" and saves them in a new file with the same name in the "core/test/acceptance" folder. PR Close #28534
2019-02-04 23:42:30 -05:00
"//packages/platform-browser/testing",
test(ivy): move render3 renderer_factory tests to acceptance (#30435) Moves all manual render3 tests which are located within the `renderer_factory_spec.ts` file to acceptance tests. A few tests that use Ivy-specific logic which is not replicable with `TestBed` remain in the render3 folder (e.g. using `renderTemplate`) Additionally migrated tests that assert the lifecycles of the renderer_factory are set to *ivy only* as the lifecycle seems to be different in Ivy. Tracked with: FW-1320 PR Close #30435
2019-05-13 13:01:55 -04:00
"//packages/platform-server",
test(ivy): move some local ref tests to use TestBed infrastructure. (#28534) When we first started writing tests for Ivy, we did not yet have a compatible compiler. For this reason, we set up the Ivy runtime tests to run with generated code that we wrote by hand (instead of real code generated by the compiler). Now that we have a working Ivy compiler and TestBed infrastructure that is compatible with Ivy, we should start writing integration tests that leverage them (no more handwritten generated code!). This will prevent bugs where the compiler code and runtime code become out of sync (which is easy if they are tested separately). And eventually, we should migrate all the existing runtime tests in "core/test/render3" to TestBed and ngtsc. To kick off this effort, this commit migrates some existing tests from "core/test/render3/exports_spec.ts" and saves them in a new file with the same name in the "core/test/acceptance" folder. PR Close #28534
2019-02-04 23:42:30 -05:00
"//packages/private/testing",
fix(ivy): module with providers are processed too early (#30688) Currently with Ivy, `ModuleWithProvider` providers are processed in order of declaration in the `NgModule` imports. This technically makes makes sense but is a potential breaking change as `ModuleWithProvider` providers are processed after all imported modules in View Engine. In order to keep the behavior of View Engine, the `r3_injector` is updated to no longer process `ModuleWithProvider` providers egarly. Resolves FW-1349 PR Close #30688
2019-05-27 14:34:01 -04:00
"//packages/router",
build: update rules_nodejs and clean up bazel warnings (#30370) Preserve compatibility with rollup_bundle rule. Add missing npm dependencies, which are now enforced by the strict_deps plugin in tsc_wrapped PR Close #30370
2019-05-09 17:51:51 -04:00
"@npm//rxjs",
build: rules_nodejs 0.26.0 & use @npm instead of @ngdeps now that downstream angular build uses angular bundles (#28871) PR Close #28871
2019-02-20 12:54:42 -05:00
"@npm//zone.js",
test(ivy): move some local ref tests to use TestBed infrastructure. (#28534) When we first started writing tests for Ivy, we did not yet have a compatible compiler. For this reason, we set up the Ivy runtime tests to run with generated code that we wrote by hand (instead of real code generated by the compiler). Now that we have a working Ivy compiler and TestBed infrastructure that is compatible with Ivy, we should start writing integration tests that leverage them (no more handwritten generated code!). This will prevent bugs where the compiler code and runtime code become out of sync (which is easy if they are tested separately). And eventually, we should migrate all the existing runtime tests in "core/test/render3" to TestBed and ngtsc. To kick off this effort, this commit migrates some existing tests from "core/test/render3/exports_spec.ts" and saves them in a new file with the same name in the "core/test/acceptance" folder. PR Close #28534
2019-02-04 23:42:30 -05:00
],
)
jasmine_node_test(
name = "acceptance",
bootstrap = ["angular/tools/testing/init_node_spec.js"],
deps = [
":acceptance_lib",
"//tools/testing:node",
build: rules_nodejs 0.26.0 & use @npm instead of @ngdeps now that downstream angular build uses angular bundles (#28871) PR Close #28871
2019-02-20 12:54:42 -05:00
"@npm//base64-js",
"@npm//source-map",
"@npm//zone.js",
test(ivy): move some local ref tests to use TestBed infrastructure. (#28534) When we first started writing tests for Ivy, we did not yet have a compatible compiler. For this reason, we set up the Ivy runtime tests to run with generated code that we wrote by hand (instead of real code generated by the compiler). Now that we have a working Ivy compiler and TestBed infrastructure that is compatible with Ivy, we should start writing integration tests that leverage them (no more handwritten generated code!). This will prevent bugs where the compiler code and runtime code become out of sync (which is easy if they are tested separately). And eventually, we should migrate all the existing runtime tests in "core/test/render3" to TestBed and ngtsc. To kick off this effort, this commit migrates some existing tests from "core/test/render3/exports_spec.ts" and saves them in a new file with the same name in the "core/test/acceptance" folder. PR Close #28534
2019-02-04 23:42:30 -05:00
],
)
test(ivy): move render3 renderer_factory tests to acceptance (#30435) Moves all manual render3 tests which are located within the `renderer_factory_spec.ts` file to acceptance tests. A few tests that use Ivy-specific logic which is not replicable with `TestBed` remain in the render3 folder (e.g. using `renderTemplate`) Additionally migrated tests that assert the lifecycles of the renderer_factory are set to *ivy only* as the lifecycle seems to be different in Ivy. Tracked with: FW-1320 PR Close #30435
2019-05-13 13:01:55 -04:00
ts_web_test_suite(
name = "acceptance_web",
deps = [
":acceptance_lib",
],
)