4

Ok。MSpecが静的メソッド/変数を使用する理由について頭を悩ませようとしています。(正確には静的メソッドではありませんが、メンバー変数デリゲートを使用すると、実質的に同じです)。

これにより、コンテキストを再利用できなくなります。それか、すべての静的変数が手動でリセットされていることを確認してください。これには、テストの分離に対する強制はありません。あるテストでいくつかの変数を設定し、次のテストでそれをチェックすると、合格すべきではないときに合格してしまいます。

これは非常に面倒になり始めています。同じコンテキストを共有しているという理由だけで、1 つの「because」ステートメントで行うことは、他のすべてのランダム テストに引き継がれるのではなく、そこにとどまるべきです。

編集-

問題は、どのようにテスト分離を「強制」するかです。たとえば、以下の仕様を見て、FooContext. should_not_throw合格するかどうか、大まかな推測をしましょう。

public class FooContext
{
    Establish context = () => Subject = new Foo();

    public static Foo Subject;
    public static int result;
    public static Exception ex;
}

public class When_getting_an_int_incorrectly : FooContext
{
    Because of = () => ex = Exception.Catch(() => result = Subject.GetInt(null)); 

    It should_throw = () => ex.ShouldNotBeNull();
}

public class When_getting_an_int_correctly : FooContext
{
    Because of = () => ex = Exception.Catch(() => result = Subject.GetInt(0));

    It should_not_throw = () => ex.ShouldBeNull();
}
4

2 に答える 2

2

これは技術的および歴史的な制限です。

  • デリゲート間で情報を共有するには、静的フィールドが必要です (Establish、Because、It、Cleanup)。
  • MSpec は rspec を模倣しようとしているので、Aaron はデリゲートが適切であると考え、今日見られる構文を 2008 年または 2009 年にリリースしたと思います。この構文は現在でも使用されています。

コンテキスト共有/コンテキスト基本クラスについて:あなたが述べていることから、概念を使いすぎているようです。グローバルな状態が問題にならないように、Establish で常に静的フィールドを初期化する必要があります。コンテキストの共有は十分に検討する必要があるため、引用すると、ランダムに発生することはありません。複雑なセットアップにはヘルパー メソッドを使用してみてください。仕様を読みやすくするのに役立ちます。

于 2013-08-10T00:47:11.170 に答える