4

スタブに関する最近の質問では、多くの回答がスタブを実装するための C# インターフェイスまたはデリゲートを提案していましたが、1 つの回答は、条件付きコンパイルを使用して、運用コードで静的バインディングを保持することを提案していました。この回答は、読んだ時点で -2 に変更されたため、少なくとも 2 人がこれは間違った回答だと本当に思っていました。おそらく、DEBUG の誤用が原因であるか、より広範な検証の代わりに固定値を使用している可能性があります。しかし、私は不思議に思わずにはいられません:

条件付きコンパイルの使用は、単体テスト スタブを実装するための不適切な手法ですか? 時々？いつも？

ありがとう。

編集-追加: 実験として例を追加したいと思います:

class Foo {
    public Foo() { .. }
    private DateTime Now { 
      get {
#if UNITTEST_Foo
        return Stub_DateTime.Now;
#else
        return DateTime.Now;
#endif
      }
    }
    // .. rest of Foo members
}

との比較

interface IDateTimeStrategy { 
    DateTime Now { get; }
}
class ProductionDateTimeStrategy : IDateTimeStrategy {
  public DateTime Now { get { return DateTime.Now; } }
}
class Foo {
    public Foo() : Foo(new ProductionDateTimeStrategy()) {}
    public Foo(IDateTimeStrategy s) { datetimeStrategy = s; .. }
    private IDateTime_Strategy datetimeStrategy;
    private DateTime Now { get { return datetimeStrategy.Now; } }
}

これにより、「DateTime.Now」への発信依存関係を C# インターフェイス経由でスタブ化できます。ただし、静的で十分な動的ディスパッチ呼び出しを追加し、オブジェクトは製品バージョンでも大きくなり、Foo のコンストラクターに新しい失敗パスを追加しました (割り当てが失敗する可能性があります)。

私はここで何も心配していませんか？これまでのフィードバックに感謝します!

4

6 に答える 6

3

本番コードをテスト コードから分離するようにしてください。さまざまなフォルダー階層を維持します..さまざまなソリューション/プロジェクト。

レガシーC++ コードの世界にいる場合を除きます。ここでは何でも構いません..条件付きブロックがコードの一部をテスト可能にするのに役立ち、利点が見られる場合..必ずそれを実行してください。ただし、最初の状態よりも乱雑にならないようにしてください。条件付きブロックを明確にコメントして区切ります。慎重に進んでください。これは、テスト ハーネスの下でレガシ コードを取得するための有効な手法です。

于 2008-09-18T21:44:19.417 に答える
2

コードをレビューする人にとって、明快さが損なわれると思います。コンテキストを理解するために、特定のコードの周りにコンディショナル タグがあることを覚えておく必要はありません。

于 2008-09-18T21:27:15.933 に答える
1

いいえ、これはひどいです。テストを本番コードにリークします（条件がオフであっても）

悪い悪い。

于 2008-09-18T21:34:16.023 に答える
1

テスト コードは明白である必要があり、テストされたコードと同じブロックに混在してはなりません。

これは、あなたが書くべきではない理由とほとんど同じです

if (globals.isTest)
于 2008-09-18T21:36:26.330 に答える
1

これがひどい別の理由を考えました：

何かをモック/スタブすることがよくありますが、そのメソッドがテスト対象に応じて異なる結果を返すようにする必要があります。これは、それを排除するか、まったく厄介なものにします。

于 2008-09-19T14:48:57.387 に答える
0

大規模なコード ベースでテスト容易性をリファクタリングする際に頼りになるツールとして役立つ場合があります。このような手法を使用して、より小さな変更を可能にし、「ビッグバン」リファクタリングを回避する方法がわかります。しかし、私はそのような手法に頼りすぎることを心配し、そのようなトリックがコード ベースで長く存続しないようにしようとします。そうしないと、アプリケーション コードが非常に複雑になり、追跡が困難になるリスクがあります。

于 2008-09-18T21:36:12.290 に答える