feat(ivy): TestBed support for reusing non-exported components (#30578)
This is a new feature of the Ivy TestBed. A common user pattern is to test one component with another. This is commonly done by creating a `TestFixture` component which exercises the main component under test. This pattern is more difficult if the component under test is declared in an NgModule but not exported. In this case, overriding the module is necessary. In g3 (and View Engine), it's possible to use an NgSummary to override the recompilation of a component, and depend on its AOT compiled factory. The way this is implemented, however, specifying a summary for a module effectively overrides much of the TestBed's other behavior. For example, the following is legal: ```typescript TestBed.configureTestingModule({ declarations: [FooCmp, TestFixture], imports: [FooModule], aotSummaries: [FooModuleNgSummary], }); ``` Here, `FooCmp` is declared in both the testing module and in the imported `FooModule`. However, because the summary is provided, `FooCmp` is not compiled within the context of the testing module, but _is_ made available for `TestFixture` to use, even if it wasn't originally exported from `FooModule`. This pattern breaks in Ivy - because summaries are a no-op, this amounts to a true double declaration of `FooCmp` which raises an error. Fixing this in user code is possible, but is difficult to do in an automated or backwards compatible way. An alternative solution is implemented in this PR. This PR attempts to capture the user intent of the following previously unsupported configuration: ```typescript TestBed.configureTestingModule({ declarations: [FooCmp, TestFixture], imports: [FooModule], }); ``` Note that this is the same as the configuration above in Ivy, as the `aotSummaries` value provided has no effect. The user intent here is interpreted as follows: 1) `FooCmp` is a pre-existing component that's being used in the test (via import of `FooModule`). It may or may not be exported by this module. 2) `FooCmp` should be part of the testing module's scope. That is, it should be visible to `TestFixture`. This is because it's listed in `declarations`. This feature effectively makes the `TestBed` testing module special. It's able to declare components without compiling them, if they're already compiled (or configured to be compiled) in the imports. And crucially, the behavior matches the first example with the summary, making Ivy backwards compatible with View Engine for tests that use summaries. PR Close #30578
This commit is contained in:

committed by
Matias Niemelä

parent
d5f96a887d
commit
deb77bd3df
@ -6,7 +6,7 @@
|
||||
* found in the LICENSE file at https://angular.io/license
|
||||
*/
|
||||
|
||||
import {Component, Directive, ErrorHandler, Inject, Injectable, InjectionToken, Input, NgModule, Optional, Pipe, ɵsetClassMetadata as setClassMetadata, ɵɵdefineComponent as defineComponent, ɵɵtext as text} from '@angular/core';
|
||||
import {Component, Directive, ErrorHandler, Inject, Injectable, InjectionToken, Input, NgModule, Optional, Pipe, ɵsetClassMetadata as setClassMetadata, ɵɵdefineComponent as defineComponent, ɵɵdefineNgModule as defineNgModule, ɵɵtext as text} from '@angular/core';
|
||||
import {TestBed, getTestBed} from '@angular/core/testing/src/test_bed';
|
||||
import {By} from '@angular/platform-browser';
|
||||
import {expect} from '@angular/platform-browser/testing/src/matchers';
|
||||
@ -371,6 +371,62 @@ describe('TestBed', () => {
|
||||
}).toThrowError();
|
||||
});
|
||||
|
||||
onlyInIvy('TestBed new feature to allow declaration and import of component')
|
||||
.it('should allow both the declaration and import of a component into the testing module',
|
||||
() => {
|
||||
// This test validates that a component (Outer) which is both declared and imported
|
||||
// (via its module) in the testing module behaves correctly. That is:
|
||||
//
|
||||
// 1) the component should be compiled in the scope of its original module.
|
||||
//
|
||||
// This condition is tested by having the component (Outer) use another component
|
||||
// (Inner) within its template. Thus, if it's compiled in the correct scope then the
|
||||
// text 'Inner' from the template of (Inner) should appear in the result.
|
||||
//
|
||||
// 2) the component should be available in the TestingModule scope.
|
||||
//
|
||||
// This condition is tested by attempting to use the component (Outer) inside a test
|
||||
// fixture component (Fixture) which is declared in the testing module only.
|
||||
|
||||
@Component({
|
||||
selector: 'inner',
|
||||
template: 'Inner',
|
||||
})
|
||||
class Inner {
|
||||
}
|
||||
|
||||
@Component({
|
||||
selector: 'outer',
|
||||
template: '<inner></inner>',
|
||||
})
|
||||
class Outer {
|
||||
}
|
||||
|
||||
@NgModule({
|
||||
declarations: [Inner, Outer],
|
||||
})
|
||||
class Module {
|
||||
}
|
||||
|
||||
@Component({
|
||||
template: '<outer></outer>',
|
||||
selector: 'fixture',
|
||||
})
|
||||
class Fixture {
|
||||
}
|
||||
|
||||
TestBed.configureTestingModule({
|
||||
declarations: [Outer, Fixture],
|
||||
imports: [Module],
|
||||
});
|
||||
|
||||
const fixture = TestBed.createComponent(Fixture);
|
||||
// The Outer component should have its template stamped out, and that template should
|
||||
// include a correct instance of the Inner component with the 'Inner' text from its
|
||||
// template.
|
||||
expect(fixture.nativeElement.innerHTML).toEqual('<outer><inner>Inner</inner></outer>');
|
||||
});
|
||||
|
||||
onlyInIvy('TestBed should handle AOT pre-compiled Components')
|
||||
.describe('AOT pre-compiled components', () => {
|
||||
/**
|
||||
@ -431,6 +487,42 @@ describe('TestBed', () => {
|
||||
const fixture = TestBed.createComponent(SomeComponent);
|
||||
expect(fixture.nativeElement.innerHTML).toBe('');
|
||||
});
|
||||
|
||||
it('should allow component in both in declarations and imports', () => {
|
||||
const SomeComponent = getAOTCompiledComponent();
|
||||
|
||||
// This is an AOT compiled module which declares (but does not export) SomeComponent.
|
||||
class ModuleClass {
|
||||
static ngModuleDef = defineNgModule({
|
||||
type: ModuleClass,
|
||||
declarations: [SomeComponent],
|
||||
});
|
||||
}
|
||||
|
||||
@Component({
|
||||
template: '<comp></comp>',
|
||||
|
||||
selector: 'fixture',
|
||||
})
|
||||
class TestFixture {
|
||||
}
|
||||
|
||||
TestBed.configureTestingModule({
|
||||
// Here, SomeComponent is both declared, and then the module which declares it is
|
||||
// also imported. This used to be a duplicate declaration error, but is now interpreted
|
||||
// to mean:
|
||||
// 1) Compile (or reuse) SomeComponent in the context of its original NgModule
|
||||
// 2) Make SomeComponent available in the scope of the testing module, even if it wasn't
|
||||
// originally exported from its NgModule.
|
||||
//
|
||||
// This allows TestFixture to use SomeComponent, which is asserted below.
|
||||
declarations: [SomeComponent, TestFixture],
|
||||
imports: [ModuleClass],
|
||||
});
|
||||
const fixture = TestBed.createComponent(TestFixture);
|
||||
// The regex avoids any issues with styling attributes.
|
||||
expect(fixture.nativeElement.innerHTML).toMatch(/<comp[^>]*>Some template<\/comp>/);
|
||||
});
|
||||
});
|
||||
|
||||
onlyInIvy('patched ng defs should be removed after resetting TestingModule')
|
||||
|
Reference in New Issue
Block a user