规范文件中的组件声明，而不是将顶级模块加载到TestBed

我有一个顶级模块AppModule的Angular（4.x）应用程序，它声明了几个自定义组件，因此它们可以在模板中使用。规范文件中的组件声明，而不是将顶级模块加载到TestBed

然而，对于茉莉/人缘测试最常用的方法似乎是使用BrowserDynamicTestingModule并在beforeEach声明任何所需的自定义组件，例如：

beforeEach(async(() => { 
    TestBed.configureTestingModule({ 
    declarations: [ MyComponent, SomeDependedUponComponent ] 
    }) 
    .compileComponents(); 
}));

考虑我们无论如何模拟的主要应用程序的环境，为什么是不是只用AppModule初始化testBed，所以每个自定义组件都可用于所有测试？喜欢的东西：

getTestBed().initTestEnvironment(
    [BrowserDynamicTestingModule, AppModule], 
    platformBrowserDynamicTesting() 
);

如果我不是失去了一些东西，这是非常接近的主要应用程序的安装，甚至降低了个体的投机/测试文件的样板代码。 Orre有什么缺点，比如性能损失？

来源

2017-10-13 Cedric Reichenbach

*考虑到我们正在模拟主应用程序的环境* - 我们当然不是。 – estus

上述方法是错误的，因为这种方式的测试实际上是集成测试，而它们应该是单元测试。

单元测试的目的是测试一个单元。添加额外的移动部件可以防止其单独进行测试，并且在其中一个设备发生故障时使问题解决复杂化。尽管TestBed仍然需要测试DI注释，但是可以使用isolated unit tests来提高隔离度，但不包括TestBed。

这种方法还需要提供集成/ e2e测试，以确保所有单元在单元测试中都得到了正确测试，并且可以真正实现互操作。

如果规格产生样板代码，可以通过适当的设置进一步改进，如here所示。

来源

2017-10-13 10:47:06 estus

够公平的，我想我看到单位与集成测试的论点。但是，最初在测试模块中声明所有组件可能仍然有意义，但是不加载整个'AppModule'，对吧？我的意思是声明只是关于可用性，但不应该影响任何功能。 –

如果它们的选择器存在于组件模板中，所有这些组件和指令将自动编译到经过测试的组件中。这在单元测试中并不是很理想。你不能嘲笑嵌套组件中的提供者，这就是问题所在。正确对待[this one]（https://stackoverflow.com/q/46601574/3731501）这种情况的最佳方式是不要让它发生。 – estus

规范文件中的组件声明，而不是将顶级模块加载到TestBed

回答

相关问题