Skip to content

Destroy listeners aren't called in TestBed #18831

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
bisubus opened this issue Aug 22, 2017 · 1 comment
Closed

Destroy listeners aren't called in TestBed #18831

bisubus opened this issue Aug 22, 2017 · 1 comment
Labels
area: testing Issues related to Angular testing features, such as TestBed freq2: medium P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent state: has PR type: bug/fix
Milestone
Backlog

Comments

@bisubus
Copy link
Contributor

bisubus commented Aug 22, 2017

I'm submitting a...


[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

Destroy listeners that are registered on PlatformRef and NgModuleRef with onDestroy aren't called on test bed teardown.

Expected behavior

It's expected that destroy listeners will be called automatically.

Minimal reproduction of the problem with instructions

A plunk:

@NgModule()
export class FooModule {
  constructor(moduleRef: NgModuleRef, platformRef: PlatformRef) {
    moduleRef.onDestroy(() => { throw 'module destroy' });
    platformRef.onDestroy(() => { throw 'platform destroy' });
  }
}

describe('tests', () => {
  beforeEach(() => {
    TestBed.resetTestEnvironment(); 
    TestBed.initTestEnvironment(
      BrowserDynamicTestingModule,
      platformBrowserDynamicTesting()
    );
  });

  beforeEach(() => {
    TestBed.configureTestingModule({ imports: [FooModule] });
  });
 
  it('test', inject([], () => {
    expect(1).toBe(1)
  });
});

What is the motivation / use case for changing the behavior?

Modules can have cleanup code that should be executed in order for them to function correctly in environments with multiple bootstraps (which TestBed tests are).

Environment


Angular version: 4.3.5
@IgorMinar IgorMinar added area: core Issues related to the framework runtime area: testing Issues related to Angular testing features, such as TestBed labels Sep 20, 2017
@ngbot ngbot bot added this to the Backlog milestone Jan 23, 2018
josephperrott added a commit to josephperrott/angular that referenced this issue Jan 23, 2018
@josephperrott
fix(core): move TestBed TestingModule reset to afterEach
222412e 
Closes angular#18831

BREAKING CHANGE: reset of TestingModule has changed from being done in a
    beforeEach to an afterEach.
@josephperrott josephperrott mentioned this issue Jan 23, 2018
Closed
3 tasks
josephperrott added a commit to josephperrott/angular that referenced this issue Jan 24, 2018
@josephperrott
fix(core): move TestBed TestingModule reset to afterEach
c367106 
Closes angular#18831

BREAKING CHANGE: reset of TestingModule has changed from being done in a
    beforeEach to an afterEach.
josephperrott added a commit to josephperrott/angular that referenced this issue Jan 24, 2018
@josephperrott
fix(core): move TestBed TestingModule reset to afterEach
44de5c2 
Closes angular#18831

BREAKING CHANGE: reset of TestingModule has changed from being done in a
    beforeEach to an afterEach.
@ngbot ngbot bot modified the milestones: Backlog, needsTriage Feb 26, 2018
@pkozlowski-opensource pkozlowski-opensource removed the area: core Issues related to the framework runtime label Mar 13, 2020
@jelbourn jelbourn added P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent and removed severity3: broken labels Oct 1, 2020
@JoostK JoostK mentioned this issue May 14, 2021
Closed
@crisbeto crisbeto mentioned this issue Jun 9, 2021
Closed
crisbeto added a commit to crisbeto/angular that referenced this issue Jun 12, 2021
@crisbeto
fix(router): error if module is destroyed before location is initialized
535689d 
This is something I ran into while working on a fix for the `TestBed` module teardown behavior for angular#18831. In the `RouterInitializer.appInitializer` we have a callback to the `LOCATION_INITIALIZED` which has to do some DI lookups. The problem is that if the module is destroyed before the location promise resolves, the `Injector.get` calls will fail. This is unlikely to happen in a real app, but it'll show up in unit tests once the test module teardown behavior is fixed.
@crisbeto crisbeto mentioned this issue Jun 12, 2021
Closed
crisbeto added a commit to crisbeto/angular that referenced this issue Jun 12, 2021
@crisbeto
fix(router): error if module is destroyed before location is initialized
853d031 
This is something I ran into while working on a fix for the `TestBed` module teardown behavior for angular#18831. In the `RouterInitializer.appInitializer` we have a callback to the `LOCATION_INITIALIZED` which has to do some DI lookups. The problem is that if the module is destroyed before the location promise resolves, the `Injector.get` calls will fail. This is unlikely to happen in a real app, but it'll show up in unit tests once the test module teardown behavior is fixed.
crisbeto added a commit to crisbeto/angular that referenced this issue Jun 13, 2021
@crisbeto
feat(core): add opt-in test module teardown configuration
0a272fd 
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 angular#18831.
@crisbeto crisbeto mentioned this issue Jun 13, 2021
Closed
crisbeto added a commit to crisbeto/angular that referenced this issue Jun 13, 2021
@crisbeto
feat(core): add opt-in test module teardown configuration
0a5748c 
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 angular#18831.
crisbeto added a commit to crisbeto/angular that referenced this issue Jun 13, 2021
@crisbeto
feat(core): add opt-in test module teardown configuration
dd2cb6e 
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 angular#18831.
crisbeto added a commit to crisbeto/angular that referenced this issue Jun 15, 2021
@crisbeto
feat(core): add opt-in test module teardown configuration
534b233 
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 angular#18831.
crisbeto added a commit to crisbeto/angular that referenced this issue Jun 17, 2021
@crisbeto
feat(core): add opt-in test module teardown configuration
05388b2 
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 angular#18831.
dylhunn pushed a commit that referenced this issue Jun 17, 2021
@crisbeto @dylhunn
fix(router): error if module is destroyed before location is initiali…
136958d 
…zed (#42560)

This is something I ran into while working on a fix for the `TestBed` module teardown behavior for #18831. In the `RouterInitializer.appInitializer` we have a callback to the `LOCATION_INITIALIZED` which has to do some DI lookups. The problem is that if the module is destroyed before the location promise resolves, the `Injector.get` calls will fail. This is unlikely to happen in a real app, but it'll show up in unit tests once the test module teardown behavior is fixed.

PR Close #42560
dylhunn pushed a commit that referenced this issue Jun 17, 2021
@crisbeto @dylhunn
fix(router): error if module is destroyed before location is initiali…
07c1ddc 
…zed (#42560)

This is something I ran into while working on a fix for the `TestBed` module teardown behavior for #18831. In the `RouterInitializer.appInitializer` we have a callback to the `LOCATION_INITIALIZED` which has to do some DI lookups. The problem is that if the module is destroyed before the location promise resolves, the `Injector.get` calls will fail. This is unlikely to happen in a real app, but it'll show up in unit tests once the test module teardown behavior is fixed.

PR Close #42560
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Jul 18, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
area: testing Issues related to Angular testing features, such as TestBed freq2: medium P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent state: has PR type: bug/fix
Projects
None yet
Milestone
Backlog
6 participants
@JoostK @IgorMinar @chuckjaz @jelbourn @pkozlowski-opensource @bisubus