A lot of our tests are wrapped in `{}` which serves no purpose, aside from increasing the nesting level and, in some cases, causing confusion. The braces appear to be a leftover from a time when all tests were wrapped in a `function main() {}`. The function declaration was removed in #21053, but the braces remained, presumably because it was easier to search&replace for `function main()`, but not to remove the braces at the same time.
PR Close#52239
* Adjusts tests to no longer rely on CommonJS features. Switches them to
ESM
* Updates test initialization files to not double-initialize Jasmine now
that bootstrap files are loaded after Jasmine. The `jasmine.boot`
setup was hacky from `rules_nodejs` and will break in the future
regardless if we e.g. use `rules_js` with actual unmodified `jasmine`.
PR Close#48521
1. Remove `zone-async-tagging` implementation from zone.js and move the
implementation to `@angular/core`, so `@angular/core` can import this
package more easily for better treeshaking.
2. Add `async tagging zone` implemenation into `@angular/core` package.
So we don't need to get the `AsyncStackTaggingZoneSpec` from `global`
instance, we can import the `class` directly for better treeshaking.
3. Only load this ZoneSpec when `ngDevMode` is `true`.
PR Close#47416
The sync-test zone is used in e.g. `describe` to raise an error when
there is asynchronous code scheduled in describe blocks. This commit
includes the zone name in such thrown errors to allow for us to include
the jasmine describe name in the error. This will be wired up in the
jasmine zonejs patches separately.
In the fake async test for `zone.js` there is some logic to test various
prefixes of the request animation frame functions. This logic does not
have any effect currently, except for generating the same test at
maximum three times.
This commit fixes the test to actually test what it meant to do
initially.
Karma jasmine updated the `jasmine-core` dependency. Jasmine is now more
strict when:
* The done callback is invoked multiple times
* The done callback is used, while a promise is also returned
* The done callback is treated as error when e.g. a number is returned
as first argument. This was the case with `requestAnimationFrame`.
Currently tests written using `waitForAsync` would be prone to Jasmine
warnings or errors (depending on the version) for tests incorrectly
invoking asynchronous jasmine `done` callbacks multiple times.
This can happen because the async test zone logic schedules the
`done` callback to be called using `setTimeout`, but this could
be invoked multiple times, causing multiple `done` invocations to
be scheduled. Most of the issues have been resolved with #45025,
but it does not solve the case of multiple tasks finished and callbacks
being scheduled.
Technically, the current logic is built in way that _should_ result in
`_finishCallbackIfDone` and eventually the `done` callback to be invoked
at maximium once. This is unfortunately not the case in some rather
advanced/unexpected scenarios (like our AngularJS upgrade tests) where
the scenario is the following (and microtasks from before the actual
`waitForAsync` spec are still completing -- which is valid):
```
1. A test `beforeEach` schedules a microtask in the ProxyZone.
2. An actual empty `it` spec executes in the AsyncTestZone` (using e.g. `waitForAsync`).
3. The `onInvoke` invokes `_finishCallbackIfDone` because the spec runs synchronously.
4. We wait the scheduled timeout (see below) to account for unhandled promises.
5. The microtask from (1) finishes and `onHasTask` is invoked.
--> We register a second `_finishCallbackIfDone` even though we have scheduled a timeout.
--> we execute the `done` callback twice because the async zone spec state is "stable"
```
Chrome has an experimental API to improve the debug experience of the
async tasks.
The details can be found here https://bugs.chromium.org/p/chromium/issues/detail?id=332624#c29
This commit add the `async stack tagging` support in the `zone.js`.
User can `import 'zone.js/plugins/async-stack-tagging';` to enable this
feature.
PR Close#46693
Updates us to version 4.0 of Jasmine and fixes some errors that were the result of us depending upon deprecated APIs. We need to do this both to stay up to date and because it was going to break eventually, because one of the Bazel packages was logging a deprecation warning that version 4.0 was required.
There were also some cases where the state of `ngDevMode` had started leaking out between tests.
PR Close#45558
Updates us to version 4.0 of Jasmine and fixes some errors that were the result of us depending upon deprecated APIs. We need to do this both to stay up to date and because it was going to break eventually, because one of the Bazel packages was logging a deprecation warning that version 4.0 was required.
There were also some cases where the state of `ngDevMode` had started leaking out between tests.
PR Close#45558
Before this change, the macrotask for `setInterval(callback, ms)` was no
longer tracked by `TaskTrackingZoneSpec` after the `callback` was
invoked for the first time. Now the periodic macrotask is tracked until
it is cancelled, e.g. `clearInterval(id)`.
BREAKING CHANGE: in TaskTrackingZoneSpec track a periodic task until it is cancelled
The breaking change is scoped only to the plugin
`zone.js/plugins/task-tracking`. If you used `TaskTrackingZoneSpec` and
checked the pending macroTasks e.g. using `(this.ngZone as any)._inner
._parent._properties.TaskTrackingZone.getTasksFor('macroTask')`, then
its behavior slightly changed for periodic macrotasks. For example,
previously the `setInterval` macrotask was no longer tracked after its
callback was executed for the first time. Now it's tracked until
the task is explicitly cancelled, e.g with `clearInterval(id)`.
fixes 45350
PR Close#45391
`AsyncTestZoneSpec` triggers jasmine `done()` function multiple times
and causes warning
```
An asynchronous function called its 'done' callback more than once. This is a bug in the spec, beforeAll, beforeEach, afterAll, or afterEach function in question. This will be treated as an error in a future version. See<https://jasmine.github.io/tutorials/upgrading_to_Jasmine_4.0#deprecations-due-to-calling-done-multiple-times> for more information
```
The reproduce case will be running some `Zone.run()` inside
`waitForAsync()`.
```
it('multiple done', waitForAsync(() => {
Zone.current.run(() => {});
Zone.current.run(() => {});
}));
```
The reason the `done()` is called in the `onInvoke()` hook is to handle
the case that the testBody is totally sync, but we should only do this
check for the entry function not for all `Zone.run()` scenario.
Another issue is if we run nested zone inside `waitForAsync()`, the
`onHasTask()` hook will be triggered multiple times, and cause `done()`
be triggered multiple times, so we need to only trigger the `done()`
when the zone is `AsyncTestZone`.
PR Close#45025
Close#40387
Currently zone.js patches `setTimeout` and keeps a `tasksByHandleId` map to keep `timerId` <-> `ZoneTask`
relationship. This is needed so that when `clearTimeout(timerId)` is called, zone.js can find the associated
`ZoneTask`. Now zone.js set the `tasksByHandleId` map in the `scheduleTask` function, but if the `setTimeout`
is running in the `FakeAsyncZoneSpec` or any other `ZoneSpec` with `onScheduleTask` hooks. The `scheduleTask`
in `timer` patch may not be invoked.
For example:
```
fakeAsync(() => {
setTimeout(() => {});
tick();
});
```
In this case, the `timerId` kept in the `tasksByHandleId` map is not cleared.
This is because the `FakeAsyncZoneSpec` in the `onScheduleTask` hook looks like this.
```
onScheduleTask(delegate, ..., task) {
fakeAsyncScheduler.setTimeout(task);
return task;
}
```
Because `FakeAsyncZoneSpec` handles the task itself and it doesn't call `parentDelegate.onScheduleTask`,
therefore the default `scheduleTask` in the `timer` patch is not invoked.
In this commit, the cleanup logic is moved from `scheduleTask` to `setTimeout` patch entry to
avoid the memory leak.
PR Close#40586
Calling `tick(0, null)` defaults `processNewMacroTasksSynchronously` flag to `true`, however calling `tick(0, null, {})` defaults `processNewMacroTasksSynchronously` to `undefined`. This is undesirable behavior since unless the flag is set explicitly it should still default to `true`.
PR Close#35814
