6

XUnit の理論と組み合わせた AutoFixture のパワーを本当に高く評価しています。私は最近、カスタマイズをカプセル化し、属性を介してテストに提供する方法を採用しました。

場合によっては、テストを実行するための 1 回限りのシナリオが必要になります。上記のように AutoDomainDataAttribute を使用する場合、IFixture を要求して、属性によって作成された同じインスタンスを取得することを期待できますか?

私のシナリオでは、コレクションなどにデフォルトで MultipleCustomization を使用しています。ただし、この 1 つのケースでは、SUT のコンストラクターに送信されるアイテムは 1 つだけです。したがって、テストメソッドを次のように定義しました。

[Theory, AutoDomainData]
public void SomeTest(IFixture fixture) {
  fixture.RepeatCount = 1;
  var sut = fixture.CreateAnonymous<Product>();
  ...
}

残念ながら、匿名の製品を作成するときに例外が発生します。これらの属性を持つメソッド パラメーターとして Product を要求すると、他のテストは正常に機能します。これは、フィクスチャ パラメータが AutoDomainDataAttribute によって作成されたものと同じであることを望んでいる、この特定のケースだけの問題です。

製品のコンストラクターは、AutoDomainData を介してインプレースで行ったカスタマイズにより、通常は 3 つの項目が入力される IEnumerable を想定しています。現在、私の DomainCustomization は、MultipleCustomization と AutMoqCustomization をこの順序で構成する CompositeCustomization です。

例外は、「InvalidCastException: タイプ 'Castle.Proxies.ObjectProxy' のオブジェクトをタイプ 'Product' にキャストできません。」です。

4

1 に答える 1

7

属性でアクティブなものと同じFixtureインスタンスが必要な場合は、次のように、カスタマイズでFixtureをそれ自体に挿入できます。

public class InjectFixtureIntoItself : ICustomization
{
    public void Customize(IFixture fixture)
    {
        fixture.Inject(fixture);
    }
}

これをAutoMoqCustomizationの前にCompositeCustomizationに追加することを忘れないでください。これは、IFixtureがインターフェイスであり、AutoMoqCustomizationが最初に来る場合は、代わりにMockインスタンス（AFAICT）を取得します。これは、動的Castleプロキシで現在発生していることです。

ただし、 Fixtureインスタンスが本当に必要な場合は、通常の命令型テストメソッドを作成してみませんか。

[Fact]
public void SomeTest()
{
    var fixture = new Fixture().Customize(new DomainCustomization());
    fixture.RepeatCount = 1;
    var sut = fixture.CreateAnonymous<Product>();
    // ...
}

それは私にははるかに簡単なようです...私も時々これを自分で行います...

それでも、問題全体を解決するために、APIまたはテストケースを別の方法で表現することはできないのではないかと思います。最近、物件を操作しなければならないことはめったにないので、RepeatCountなぜそんなことをしたいのだろうか。

それはおそらく別のStackOverflowの質問の主題ですが...

于 2012-10-29T20:27:12.893 に答える