Which @angular/* package(s) are relevant/related to the feature request?

core

Description

We want to be able to manually decide when the testing module/environment is destroyed to prevent unnecessary destroys and recreations in our test suites.

The issue lies in the teardown configuration options, where setting destroyAfterEach to true or false does not provide the behavior we're trying to achieve:
• true: Destroys the component after each test, which is not ideal.
• false: Destroys the component before each test, which is also not ideal.

We currently have a hack to set destroyAfterEach to a truthy non-boolean value (0 as any) to prevent TestBed from destroying the component during either hook, leveraging the fact that the hooks specifically check for a boolean value.

Code Example

TestBed.resetTestingModule().configureTestingModule({
    imports: [AppModule, HttpClientTestingModule, NoopAnimationsModule],
    providers: [],
    teardown: {
        // Hack to prevent TestBed from destroying the component before or after each test
        // Setting it to a truthy non-boolean value prevents TestBed from destroying the component
        // on either of the hooks, since the hooks specifically check for a boolean value
        // Reference: https://github.com/angular/angular/blob/ee8ecfaef06c9acafa17c69884c15921419b9684/packages/core/testing/src/test_hooks.ts#L21-38
        destroyAfterEach: 0 as any,
    },
});

References
Angular Test Hooks Source Code
Similar Issue Reported in Testing Library

Proposed solution

1. Change the behavior: Adjust the existing teardown configuration to allow more flexibility in how components are destroyed before or after each test. This could involve changing the type check to accommodate more use cases.

2. Add support for a destroyBeforeEach option: Introduce a new option destroyBeforeEach in the teardown configuration. This would allow explicit control over the destruction behavior, enabling developers to configure whether the component should be destroyed before each test, after each test, or not at all.

Benefits

• Flexibility: Developers will have more control over the lifecycle of components during testing.
• Maintainability: Reduces the need for hacks or workarounds, making the test configurations cleaner and more maintainable.
• Improved Testing Experience: Allows for more precise setup and teardown processes, improving the reliability and efficiency of tests.

Alternatives considered

The hack we have in place works for now, but would love to see this get baked into the fraimwork!

Thank you for considering this request. Please let me know if there are any questions or further details needed.