TestBedにトップレベルモジュールをロードするのではなく、スペックファイルのコンポーネント宣言

Question

トップレベルモジュールAppModuleを持つAngular（4.x）アプリケーションがあります。これはいくつかのカスタムコンポーネントを宣言しているので、テンプレート。

しかし、ジャスミン/カルマのための最も一般的なアプローチはBrowserDynamicTestingModuleを使用しているように見えるテストとbeforeEach時に必要なすべてのカスタムコンポーネントを宣言し、例えば：

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

我々はとにかく、メインアプリケーションの環境をシミュレートしている考えると、なぜAppModuleでtestBedを初期化しないので、すべてのカスタムコンポーネントがすべてのテストで使用できますか？ような何か：私は何かが欠けていないよ場合

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

が、これは、メインアプリケーションのセットアップにかなり近いとさえ、個々のスペック/テストファイルに定型的なコードを減らしています。パフォーマンスペナルティのような不利な点はありませんか？

Answer 1

この方法は、このようにテストが事実上の統合テストであり、単体テストであると考えられるため、このアプローチは間違っています。

ユニットテストの目的は、単一のユニットをテストすることです。追加の可動部品を追加することで、それが孤立してテストされることを防ぎ、ユニットの1つが故障したときのトラブル解決を複雑にします。 TestBedを使用せずにisolated unit testsで分離を改善することができますが、TestBedはまだDI注釈をテストする必要があります。

このアプローチでは、すべてのユニットが単体テストで適切にテストされ、実際に相互運用できることを確認するために統合/ e2eテストを提供する必要があります。

仕様で定型記号が使用されている場合は、hereのように適切な設定でさらに改善できます。