1

Ninjectを使用して、次のものがあり、FluentAssertionsを使用してテストしたいと考えています。

[Test]
public void InterfacesEndingWithFactoryShouldBeBoundAsFactories() {
    // Given
    IKernel kernel = new StandardKernel();
    kernel.Bind(services => services
        .From(AppDomain.CurrentDomain
            .GetAssemblies()
            .Where(a => !a.FullName.Contains("Tests")))
        .SelectAllInterfaces()
        .EndingWith("Factory")
        .BindToFactory()
    );

    // When
    var factory = kernel.Get<ICustomerManagementPresenterFactory>();

    // Then
    factory.Should().NotBeNull();
}

工場が実際に適切にバインドされているかどうかをテストする良い方法はありますか?

4

2 に答える 2

1

まず、影響を受けるタイプと影響を受けないタイプをテストする ninject インフラストラクチャがありません。単体テストは、構文が流暢であり、メソッドを呼び出すときに返される多くのインターフェイスであるため、非常に複雑です。したがって、実際にできることは統合テストだけです。

さて、私の意見では、From(...)問題があります。に渡すアセンブリを置き換えることができるコンポーネントを作成する場合は、いくつかのタイプを含む追加のテスト アセンブリを作成してから、バインドされていないか、バインドされているか、バインドされていないFromかをテストします。機能統合テスト。interface IFoointerface IFooFactoryclass Foo

ただし、バインディングがなく、コンストラクター引数として使用されている場合、ninject は例外をスローすることを考慮しIFooFactoryてSomeClassくださいIFooFactory。コンポジション ルートがある場合は、アプリケーションを起動するだけで、必要なバインディングが存在するかどうかがわかります。

このテストは、ファクトリ コンベンションの統合テストよりもさらに便利です。誰かが工場を手動で誤ってバインドしたかどうかを検討してください。これは規約統合テストでは表示されませんが、アプリケーションを開始すると、ninject はこの 1 つのインターフェースに複数のバインディングがあることを示す例外をスローします。

于 2014-09-11T05:55:48.927 に答える