This adds a test module configuration to define whether animations should be enabled or disabled in test. By default, they are disabled.
PR Close#62764
Currently when testing a component using `TestBed.createComponent`, we always create the component as a `div` which isn't aligned with the runtime. The runtime tries to parse out the tag name from the first selector in `@Component` and only falls back to `div` if there isn't one. This behavior difference can cause components to not behave like they would in production which reduces the usefulness of the tests.
These changes add the `inferTagName` option to `TestBed.createComponent` and `TestBed.configureTestingModule` that allows apps to opt into inferring the tag name from the selector in the same way as the runtime. Currently the new option is set to `false`, but we intend to change it to `true` in a future version.
PR Close#62283
Adds support for passing in `Binding` objects into `TestBed.createComponent`. This makes it easier to test components by avoiding the need to create a wrapper component. Furthermore, it keeps the behavior consistent between tests and the actual app. For example, given a custom checkbox that looks like this:
```typescript
@Component({
selector: 'my-checkbox',
template: '...',
host: {'[class.checked]': 'isChecked()'}
})
export class MyCheckbox {
isChecked = input(false);
}
```
A test for the `isChecked` input would look something like this:
```typescript
it('should toggle the checked class', () => {
@Component({
imports: [MyCheckbox],
template: '<my-checkbox [isChecked]="isChecked"/>',
})
class Wrapper {
isChecked = false;
}
const fixture = TestBed.createComponent(Wrapper);
const checkbox = fixture.nativeElement.querySelector('my-checkbox');
fixture.detectChanges();
expect(checkbox.classList).not.toContain('checked');
fixture.componentInstance.isChecked = true;
fixture.detectChanges();
expect(checkbox.classList).toContain('checked');
});
```
Whereas with the new API, the test would look like this:
```typescript
it('should toggle the checked class', () => {
const isChecked = signal(false);
const fixture = TestBed.createComponent(MyCheckbox, {
bindings: [inputBinding('isChecked', isChecked)]
});
const checkbox = fixture.nativeElement.querySelector('my-checkbox');
fixture.detectChanges();
expect(checkbox.classList).not.toContain('checked');
isChecked.set(true);
fixture.detectChanges();
expect(checkbox.classList).toContain('checked');
});
```
PR Close#62040
`fakeAsync` does not work if the zone-testing polyfill is included after
@angular/core/testing is loaded. This allows fakeAsync to work
even if the zone-testing is included later.
PR Close#61375
This ensures that `TestBed.tick` updates any components created with
`TestBed.createComponent`, regardless of whether autoDetectChanges is
on.
PR Close#61382
Our intention was to remove TestBed.flushEffects() in Angular v20
as it was a developer preview API that doesn't need to follow our
deprecation policy. It turned out, though, that the angular.dev
documentation wasn't displaying the @developerPreview annotation
properly so some of the developers might have been unaware of the
non-stable nature of this API.
This commits re-introduces the TestBed.flushEffects() API. This
API call will delegate to TestBed.tick().
PR Close#61462
After nearly a decade of existence, there are 0 uses of
`autoDetectChanges(false)` internally. All uses of
`autoDetectChanges(true)` can be migrated directly to
`autoDetectChanges()` instead.
PR Close#61429
This prevents `core/testing` from throwing an error if ZoneJS is present
but does not patch the test FW APIs such that `fakeAsync` works
automatically. For example, there is currently no patching of the vitest
APIs, so if you try to use Vitest with Zone on the page, it will throw.
PR Close#61376
This aligns with how angular/components marks their hidden APIs.
`@nodoc` has been broken since the switch to adev, this change should
properly hide the APIs again.
PR Close#61194
This commit removes the use of the privately exported
PendingTasksInternal everywhere except for Router. A follow-up change
will be done to remove that one as well and delete the private export.
PR Close#61049
Expose `getCleanupHook` as a private export to address integration issues with Vitest. In Vitest, `globalThis.beforeEach` and `globalThis.afterEach` are not available by default. Additionally, these hooks are patched during module evaluation, complicating seamless integration with Vitest.
See: https://github.com/angular/angular-cli/pull/30188
PR Close#61017
This commit introduces the `TestBed.tick()` method that,
similarly to the `ApplicationRef.tick()`, synchronizes state
with the DOM. It can be used in unit tests to mimic framework's
logic executed in production applications. The `TestBed.tick()`
should be used instead of the removed `TestBed.flushEffects()`.
BREAKING CHANGE: the `TestBed.flushEffects()` was removed - use
the `TestBed.tick()` instead.
PR Close#60993
Instead of stabilizing the TestBed.flushEffects() API we intend to
replace it with the tick() method (equivalent of ApplicationRef.tick().
The reasoning here is that we prefer tests running the entire
synchronization process (as in production apps) instead of invoking
parts of the synchronization process in a way that would naver happen
in a running application.
PR Close#60959
In this commit, we unsubscribe the `hasPendingTasks` subject to remove all active observers and enable granular garbage collection, as users may forget to unsubscribe manually when subscribing to `isStable`.
PR Close#59723
This commit moves `DOMTestComponentRenderer` to `@angular/platform-browser/testing`, allowing the Angular CLI to eliminate its dependency on `@angular/platform-browser-dynamic`, which would no longer be required for new projects.
PR Close#60453
`TestBed.get` isn't type safe and has been deprecated for several years now. These changes remove it from the public API and a follow-up change will add an automated migration to `TestBed.inject`.
BREAKING CHANGE:
* `TestBed.get` has been removed. Use `TestBed.inject` instead.
PR Close#60414
Removes the deprecated `InjectFlags` symbol from the `@angular/core` public API, as well as all the places that accept it. The previous commit includes an automated migration to switch over to the new way of passing in flags.
BREAKING CHANGE:
* `InjectFlags` has been removed.
* `inject` no longer accepts `InjectFlags`.
* `Injector.get` no longer accepts `InjectFlags`.
* `EnvironmentInjector.get` no longer accepts `InjectFlags`.
* `TestBed.get` no longer accepts `InjectFlags`.
* `TestBed.inject` no longer accepts `InjectFlags`.
PR Close#60318
This moves the `FakeNavigation` implementation to the primitives folder
so its implementation can be shared with Wiz. This class was initially
copied directly from the Wiz implementation, with some small modifications.
There will still need to be some work done to align the implementations
and fix anything internally that needs adjusting.
PR Close#59857
This commit is part of the migration to standalone by default and sets up 2 files with a default value for standalone. They are still `false` in this case to land the change into G3 first. The switch to `true` will be executed in a follow-up PR.
PR Close#58175
The original effect design for Angular had one "bucket" of effects, which
are scheduled on the microtask queue. This approach got us pretty far, but
as developers have built more complex reactive systems, we've hit the
limitations of this design.
This commit changes the nature of effects significantly. In particular,
effects created in components have a completely new scheduling system, which
executes them as a part of the change detection cycle. This results in
behavior similar to that of nested effects in other reactive frameworks. The
scheduling behavior here uses the "mark for traversal" flag
(`HasChildViewsToRefresh`). This has really nice behavior:
* if the component is dirty already, effects run following preorder hooks
(ngOnInit, etc).
* if the component isn't dirty, it doesn't get change detected only because
of the dirty effect.
This is not a breaking change, since `effect()` is in developer preview (and
it remains so).
As a part of this redesigned `effect()` behavior, the `allowSignalWrites`
flag was removed. Effects no longer prohibit writing to signals at all. This
decision was taken in response to feedback / observations of usage patterns,
which showed the benefit of the restriction did not justify the DX cost.
The new effect timing is not yet enabled - a future PR will flip the flag.
PR Close#56501
When disabling autodetect (not recommeneded) with zoneless,
`fixture.detectChanges` would previously not refresh the fixture's component.
PR Close#57416
Disabling `checkNoChanges` in `ComponentFixture.detectChanges` was an
error for the zoneless fixture since it was not yet working. This now
allows checkNoChanges to be disabled. This option isn't really
used/shouldn't be used by anyone except the FW so marked as a refactor.
PR Close#57416
This commit removes the abstract base class and two separate
implementations of `ComponentFixture` for zone vs zoneless. Now that the
behaviors have gotten close enough to the same, the diverged concrete
implementations serve less value. Instead, the different behaviors can
be easily handled in if/else branches. The difference is now limited to
the default for `autoDetect` and how `detectChanges` functions.
PR Close#57416
This commit moves the ngZone onError subscription to the base fixture
implementation. While this subscription isn't necessary for zoneless, it does
no harm because the observable never emits.
PR Close#57416
This commit updates the implementations of `autoDetectChanges` to be
shared between the zone-based and zoneless fixtures. This now allows
`autoDetect` to be turned off for zoneless fixtures after it was
previously on because the host view is no longer directly attached to
`ApplicationRef`.
PR Close#57416
This commit fully integrates the `autoDetect` feature into
`ApplicationRef.tick` without special handling for errors.
This commit also shares the method of autoDetect for change detection between
the zoneless and zone component fixture implementations. The difference
is now limited to:
* autoDetect is defaulted to true with zoneless
* detectChanges with zoneless is AppRef.tick while it is
ChangeDetectorRef.detectChanges with zones. This should likely
converge more in the future. Not going through AppRef.tick means that
the zone fixture does not get guaranteed `afterRender` executions and
does not get the rerunning behavior if the fixture is marked dirty by
a render hook.
BREAKING CHANGE: The `autoDetect` feature of `ComponentFixture` will now
attach the fixture to the `ApplicationRef`. As a result, errors during
automatic change detection of the fixture be reported to the `ErrorHandler`.
This change may cause custom error handlers to observe new failures that were previously unreported.
PR Close#55228
Errors during change detection from `ApplicationRef.tick` are only
reported to the `ErrorHandler`. By default, this only logs the error to
console. As a result, these errors can be missed/ignored and allow tests
to pass when they should not. This change ensures that the errors are
surfaced. Note that this is already the behavior when zoneless is
enabled.
BREAKING CHANGE: Errors that are thrown during `ApplicationRef.tick`
will now be rethrown when using `TestBed`. These errors should be
resolved by ensuring the test environment is set up correctly to
complete change detection successfully. There are two alternatives to
catch the errors:
* Instead of waiting for automatic change detection to happen, trigger
it synchronously and expect the error. For example, a jasmine test
could write `expect(() => TestBed.inject(ApplicationRef).tick()).toThrow()`
* `TestBed` will reject any outstanding `ComponentFixture.whenStable` promises. A jasmine test,
for example, could write `expectAsync(fixture.whenStable()).toBeRejected()`.
As a last resort, you can configure errors to _not_ be rethrown by
setting `rethrowApplicationErrors` to `false` in `TestBed.configureTestingModule`.
PR Close#57200
From the internal issue on the matter:
> When using the standard Jasmine version of it promises returned by the body function are automatically awaited. The Catalyst version of it is fake-async, so awaiting the promise does not make sense; however it would be nice if Catalyst automatically flushed the promise to replicate the experience of using standard it. This would allow users to do the following:
```
it('should fail later', async () => {
await new Promise(r => setTimeout(r));
fail('failure');
});
```
> In Catalyst today the above test will pass. If this proposal to automatically flush the resulting promise were implemented it would fail.
Flushing after the tests complete has been the default behavior inside
Google since 2020. Very few tests remain that use the old behavior of
only flushing microtasks. The example above would actually fail with
`fakeAsync` due to the pending timer, but the argument still remains the
same. We might as well just flush if we're going to fail the test
anyways by throwing if there's no flush at the end.
PR Close#57239
This creates a private option that can be used internally while we
migrate this to the default and only behavior. ~200 tests in TGP have errors
that are being swallowed (console.log) and not causing the test to fail.
We can first explicitly opt those out, flip the default internally, then
"fix" them by adding expect...toThrow.
PR Close#57153
