2つの具象インスタンスを注入する場合、2番目のインスタンスが最初のインスタンスをオーバーライドします。
具体的なインスタンスを挿入し、その後にモックされたインスタンスを挿入する場合、2番目のインスタンスは最初のインスタンスをオーバーライドしません。
これにより、モックを使用するいくつかのテストと実装を使用するいくつかのテスト(テストクラスコンストラクターを使用してテスト間でフィクスチャを共有する)を実行するという考えはかなり厄介になります。
2つの具象インスタンスを注入する場合、2番目のインスタンスが最初のインスタンスをオーバーライドします。
具体的なインスタンスを挿入し、その後にモックされたインスタンスを挿入すると、2番目のインスタンスが最初のインスタンスをオーバーライドします。
`` `C#
System.Collections.Genericを使用する;
AutoFixtureを使用します。
AutoFixture.AutoMoqを使用します。
Moqを使用します。
Xunitを使用する;
名前空間SomeNamespace
{{
パブリッククラスAutoFixtureTests
{{
[事実]
//合格
public void Should_OverridePreviouslyInjectedString()
{{
const string test1 = "test1";
const string test2 = "test2";
var fixture = new Fixture();
fixture.Inject(test1);
fixture.Inject(test2);
Assert.Equal(fixture.Create<string>(), test2);
}
[Fact]
// Fails
public void Should_OverridePreviouslyInjectedInstance()
{
var fixture = new Fixture().Customize(new AutoMoqCustomization());
var sut1 = new List<int>();
fixture.Inject<IList<int>>(sut1);
fixture.Freeze<Mock<IList<int>>>();
var sut2 = fixture.Create<IList<int>>();
Assert.NotSame(sut1, sut2);
}
}
}
`` `
こんにちは@ charles-salmon、
これを報告するために時間を割いていただきありがとうございます。
観察している動作は_設計による_です。 説明させてください。 🙂
Freeze<T>
メソッドの実装を見ると:
var value = fixture.Create<T>();
fixture.Inject(value);
return value;
T
標本を作成し、それをフィクスチャに注入するだけであることがわかります。 実際、 Freeze
メソッドは、まさにこの操作の便利なショートカットとして生まれました。 @ploehが2010年にフリーズメソッドを紹介した彼の投稿に書いたよう
このコーディングイディオムを多用したため、便利な方法でカプセル化することにしました。 いくつかの議論の末、Freezeという名前にたどり着きました。これは、新しいインスタンスを作成するためのデフォルトのアルゴリズムをバイパスして、基本的にフィクスチャ内の単一の匿名変数をフリーズするためです。
それを考えると、注入されたインスタンスと同じタイプT
をフリーズすると、同じインスタンスが生成されるのは当然のことです。
さて、あなたのポイントに対処するために:
これにより、モックを使用するいくつかのテストと実装を使用するいくつかのテスト(テストクラスコンストラクターを使用してテスト間でフィクスチャを共有する)を実行するという考えはかなり厄介になります。
フィクスチャがテストが実行される_context_を表すことを考えると、複数のテストが同じフィクスチャを共有することは確かに_できます_。 ただし、これには、複数の、場合によっては矛盾する懸念が混在するという犠牲が伴います。
xUnitパターンの本はそれをうまくまとめています:
共有フィクスチャの最大の問題は、テストが他のテストの結果に依存する可能性があるため、テスト間の「衝突」が発生し、エラーテストが発生する可能性があることです。 もう1つの問題は、多くのテストに対応するように設計されたフィクスチャは、単一のテストに必要な
この「衝突」は、テストでタイプT
オブジェクトが特定のインスタンスであると想定し、別のテストでT
が偽のオブジェクトであると想定した場合に発生し
同じタイプのT
がモックと具体的なインスタンスの両方であることが理にかなっているテストシナリオを考えることはできないので(間違っていることが証明されてうれしいですが)、これらを持っていることをお勧めしますテストではさまざまなフィクスチャを使用し、それぞれが特定のシナリオに対応するように構成されています。
最も参考になるコメント
こんにちは@ charles-salmon、
これを報告するために時間を割いていただきありがとうございます。
観察している動作は_設計による_です。 説明させてください。 🙂
Freeze<T>
メソッドの実装を見ると:T
標本を作成し、それをフィクスチャに注入するだけであることがわかります。 実際、Freeze
メソッドは、まさにこの操作の便利なショートカットとして生まれました。 @ploehが2010年にフリーズメソッドを紹介した彼の投稿に書いたようそれを考えると、注入されたインスタンスと同じタイプ
T
をフリーズすると、同じインスタンスが生成されるのは当然のことです。さて、あなたのポイントに対処するために:
フィクスチャがテストが実行される_context_を表すことを考えると、複数のテストが同じフィクスチャを共有することは確かに_できます_。 ただし、これには、複数の、場合によっては矛盾する懸念が混在するという犠牲が伴います。
xUnitパターンの本はそれをうまくまとめています:
この「衝突」は、テストでタイプ
T
オブジェクトが特定のインスタンスであると想定し、別のテストでT
が偽のオブジェクトであると想定した場合に発生し同じタイプの
T
がモックと具体的なインスタンスの両方であることが理にかなっているテストシナリオを考えることはできないので(間違っていることが証明されてうれしいですが)、これらを持っていることをお勧めしますテストではさまざまなフィクスチャを使用し、それぞれが特定のシナリオに対応するように構成されています。