dde68ff954
* it's tricky to get out of the runfiles tree with `bazel test` as `BUILD_WORKSPACE_DIRECTORY` is not set but I employed a trick to read the `DO_NOT_BUILD_HERE` file that is one level up from `execroot` and that contains the workspace directory. This is experimental and if `bazel test //:test.debug` fails than `bazel run` is still guaranteed to work as `BUILD_WORKSPACE_DIRECTORY` will be set in that context * test //integration:bazel_test and //integration:bazel-schematics_test exclusively * run "exclusive" and "manual" bazel-in-bazel integration tests in their own CI job as they take 8m+ to execute ``` //integration:bazel-schematics_test PASSED in 317.2s //integration:bazel_test PASSED in 167.8s ``` * Skip all integration tests that are now handled by angular_integration_test except the tests that are tracked for payload size; these are: - cli-hello-world* - hello_world__closure * add & pin @babel deps as newer versions of babel break //packages/localize/src/tools/test:test @babel/core dep had to be pinned to 7.6.4 or else //packages/localize/src/tools/test:test failed. Also //packages/localize uses @babel/generator, @babel/template, @babel/traverse & @babel/types so these deps were added to package.json as they were not being hoisted anymore from @babel/core transitive. NB: integration/hello_world__systemjs_umd test must run with systemjs 0.20.0 NB: systemjs must be at 0.18.10 for legacy saucelabs job to pass NB: With Bazel 2.0, the glob for the files to test `"integration/bazel/**"` is empty if integation/bazel is in .bazelignore. This glob worked under these conditions with 1.1.0. I did not bother testing with 1.2.x as not having integration/bazel in .bazelignore is correct. PR Close #33927 |
||
---|---|---|
.. | ||
goldens | ||
project | ||
.gitignore | ||
README.md | ||
generate.ts | ||
matcher.ts | ||
package.json | ||
test.ts | ||
tsclient.ts | ||
tsconfig.json | ||
yarn.lock |
README.md
Angular Language Service Test
This directory is an integration test for @angular/language-service
to ensure
that the language service works correctly as a tsserver
plugin.
To use the tests:
- Use
yarn install
to install all dependencies in this directory and in the Angular repo root directory. - Build an Angular distribution with
yarn build-dist
. This needs to be done after changes to Angular, but not after changes to integration tests. This is an expensive build. - In this directory, run the integration tests with
yarn test
.
Update golden files
If the expected output needs to be updated, run yarn golden my-golden.json
, replacing
my-golden.json
with the golden file to be updated. Do not qualify the file with a directory path.
See generate.ts for more information.
Adding a new fixture
Currently there is no automated way to produce a new fixture. The way the
current fixtures were created was to hack a version of tsserver.js to write the
commands from VSCode
to a file while performing the operation to be tested.
I also hand modified the input to remove superfluous request.
Once a new fixture is created:
- Add the fixture name to
goldens/
- Run
yarn golden my-golden.json
, replacingmy-golden.json
with the new fixture name, to produce the expected output files. - Hand validate that the expected output is reasonable.