When the zoneless scheduler is provided, we want to update the behavior
of `ComponentFixture` to address common issues and painpoints in testing.
Developers should never have to call `detectChanges` on a fixture
manually. Instead of calling `detectChanges` after performing an
action that updates state and requies a template refresh, developers
should wait for change detection to run because the update needs to also have
notified the scheduler. If this was not the case, the component would
not work correctly in the application. Calling `detectChanges` to force
an update could hide real bugs.
This commit also updates the zoneless tests to uses `ComponentFixture`
instead of manually attaching to the `ApplicationRef` and rewriting a
lot of the helpers (`getDebugNode`, `isStable` as a value, `whenStable` as a
Promise).
PR Close#54024
The component fixture dependencies have to be passed in manually. This
is a bit annoying to manage as we expand which dependencies are needed.
Instead, we can run the constructor in the TestBed injection context and
move the dependencies into the component fixture code, as is done with
other constructors in Angular.
PR Close#53400
Previously effects were queued as they became dirty, and this queue was
flushed at various checkpoints during the change detection cycle. The result
was that change detection _was_ the effect runner, and without executing CD,
effects would not execute. This leads a particular tradeoff:
* effects are subject to unidirectional data flow (bad for dx)
* effects don't cause a new round of CD (good/bad depending on use case)
* effects can be used to implement control flow efficiently (desirable)
This commit changes the scheduling mechanism. Effects are now scheduled via
the microtask queue. This changes the tradeoffs:
* effects are no longer limited by unidirectional data flow (easy dx)
* effects registered in the Angular zone will trigger CD after they run
(same as `Promise.resolve` really)
* the public `effect()` type of effect probably isn't a good building block
for our built-in control flow, and we'll need a new internal abstraction.
As `effect()` is in developer preview, changing the execution timing is not
considered breaking even though it may impact current users.
PR Close#51049
TestBed.overrideProvider should include `multi` support in its type. The
underlying implementation already supports it, as documented by the
tests which are currently casting the override to `any` to get around
the bad type.
PR Close#48424
This commit adds `TestBed.runInInjectionContext` which is equivalent to
`TestBed.inject(EnvironmentInjector).runInContext`. This function will
help make tests for functions which call `inject` from `@angular/core` a
little bit less verbose.
PR Close#47955
This commit applies the changes similar to the ones performed for the `inject()` function in df246bb235.
The `TestBed.inject` function is updated to use previously added object-based API for options: now the flags argument supports passing an object which configures injection flags.
DEPRECATED:
The bit field signature of `TestBed.inject()` has been deprecated, in favor of the new options object.
PR Close#46761
This commit performs various refactoring of the TestBed code to better align interfaces and implementation. The implementation class is also renamed from `TestBedRender3` -> `TestBedImpl`, but the public API name has not changed.
Note: as a part of this change, the TestBed interface became more consistent and typings for multiple methods were updated to account for the fact that the TestBed reference is returned. This was always a runtime behavior of TestBed, which was not reflected in few places in type.
PR Close#46635
This allows the documentation for the options `errorOnUnknownElements` and `errorOnUnknownProperties` to be displayed in the docs.
They aren't currently displayed, as `TestModuleMetadata` is a type and not an interface.
See https://next.angular.io/api/core/testing/TestModuleMetadata
PR Close#45891
Allows to provide a TestBed option to throw on unknown properties in templates:
```ts
getTestBed().initTestEnvironment(
BrowserDynamicTestingModule,
platformBrowserDynamicTesting(), {
errorOnUnknownProperties: true
}
);
```
The default value of `errorOnUnknownProperties` is `false`, so this is not a breaking change.
PR Close#45853
Allows to provide a TestBed option to throw on unknown elements in templates:
```ts
getTestBed().initTestEnvironment(
BrowserDynamicTestingModule,
platformBrowserDynamicTesting(), {
errorOnUnknownElements: true
}
);
```
The default value of `errorOnUnknownElements` is `false`, so this is not a breaking change.
PR Close#45479
Allows to provide a TestBed option to throw on unknown elements in templates:
```ts
getTestBed().initTestEnvironment(
BrowserDynamicTestingModule,
platformBrowserDynamicTesting(), {
errorOnUnknownElements: true
}
);
```
The default value of `errorOnUnknownElements` is `false`, so this is not a breaking change.
PR Close#45479
BREAKING CHANGE:
Since Ivy, TestBed doesn't use AOT summaries. The `aotSummaries` fields in TestBed APIs were present, but unused. The fields were deprecated in previous major version and in v14 those fields are removed. The `aotSummaries` fields were completely unused, so you can just drop them from the TestBed APIs usage.
PR Close#45487
The API golden Bazel rule has changed in the shared dev-infra code. Instead
of putting golden API reports into the golden folder as per their original
location in the NPM package, golden reports are now stored based on the
package exports. This makes it more obvious how entry-points are consumable
As part of this change, since the API golden rule now consutls the NPM package
`exports` field, the `localize/tools` entry-point golden file is now generated.
Previously it wasn't generated due to it not having a secondary entry-point
`package.json` file. Such package json files should not be needed anymore
and will be gone in future APF versions.
PR Close#45461
DEPRECATION:
In Ivy, AOT summary files are unused. Passing AOT summary files in TestBed has no effect, so the `aotSummaries` usage in TestBed is deprecated and will be removed in a future version of Angular.
PR Close#43395
We currently have two long-standing issues related to how `TestBed` tests are torn down:
1. The dynamically-created test module isn't going to be destroyed, preventing the `ngOnDestroy` hooks on providers from running and keeping the component `style` nodes in the DOM.
2. The test root elements aren't going to be removed from the DOM. Instead, they will be removed whenever another test component is created.
By themselves, these issues are easy to resolve, but given how long they've been around, there are a lot of unit tests out there that depend on the broken behavior.
These changes address the issues by introducing APIs that allow users to opt into the correct test teardown behavior either at the application level via `TestBed.initTestEnvironment` or the test suite level via `TestBed.configureTestingModule`.
At the moment, the new teardown behavior is opt-in, but the idea is that we'll eventually make it opt-out before removing the configuration altogether.
Fixes#18831.
PR Close#42566
Currently we have a lot of places where we repeat the type `Type<T>|AbstractType<T>|InjectionToken<T>` which makes it cumbersome to add another type or to type something else with the same signature.
These changes add a new type that can be used instead.
Fixes#39792.
PR Close#41580
```
export const __core_private_testing_placeholder__ = '';
```
This API should be removed. But doing so seems to break `google3` and
so it requires a bit of investigation. A work around is to mark it as
`@codeGenApi` for now and investigate later.
PR Close#38274
Moves the public api .d.ts files from tools/public_api_guard to
goldens/public-api.
Additionally, provides a README in the goldens directory and a script
assist in testing the current state of the repo against the goldens as
well as a command for accepting all changes to the goldens in a single
command.
PR Close#35768
