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:
Alex Rickabaugh
2019-05-20 16:49:20 -07:00
committed by Matias Niemelä
parent d5f96a887d
commit deb77bd3df
3 changed files with 157 additions and 33 deletions

View File

@ -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')