静的クラス/メソッド/プロパティをユニットテスト開発環境で使用する必要がありますか?これもテスト不可能なラッパーを導入せずにテストする方法はありませんか?
もう 1 つのシナリオは、単体テスト対象内で静的メンバーが使用されている場合、静的メンバーをモックできないことです。したがって、単体テスト対象をテストするときに、静的メンバーをテストする必要があります。静的メンバーが計算を実行するときにそれを分離したい。
静的クラス/メソッド/プロパティをユニットテスト開発環境で使用する必要がありますか?これもテスト不可能なラッパーを導入せずにテストする方法はありませんか?
もう 1 つのシナリオは、単体テスト対象内で静的メンバーが使用されている場合、静的メンバーをモックできないことです。したがって、単体テスト対象をテストするときに、静的メンバーをテストする必要があります。静的メンバーが計算を実行するときにそれを分離したい。
静的メソッドのテストは、他のメソッドのテストと同じです。別のテスト済みモジュール内で静的メソッドを依存関係として持つと、問題が発生します (言及されているように、無料のツールでモック/スタブすることはできません)。ただし、静的メソッド自体が単体テストされている場合は、それを機能する信頼できるコンポーネントとして単純に扱うことができます。
全体として、次の場合、静的メソッドを使用しても問題はありません (つまり、単体テスト/TDD を中断しません)。
Math.Floor
できると見なされる可能性があります。これを使用しても、「注意してください、静的です!」という警告が発生することはありません。想定される場合があります)。マイクロソフトはその仕事をします)静的メソッドが問題を引き起こし、回避する必要があるのはいつですか? 基本的に、彼らがあなたが制御できない(またはモックする)何かとやり取りしたり、何かをしたりする場合にのみ:
編集: 静的メソッドが単体テストを困難にする場合の2つの例
1
public int ExtractSumFromReport(string reportPath)
{
var reportFile = File.ReadAllText(reportPath);
// ...
}
どのように対処しFile.ReadAllText
ますか?これは明らかにファイル システムに移動してファイル コンテンツを取得しますが、これは単体テストでは絶対にダメです。これは、外部依存関係を持つ静的メソッドの例です。これを回避するには、通常、ファイル システム API の周りにラッパーを作成するか、単純に依存関係/デリゲートとして挿入します。
2
public void SaveUser(User user)
{
var session = SessionFactory.CreateSession();
// ...
}
これはどうですか?セッションは重要な依存関係です。確かに、それは のようになるかもしれませんが、モックを返すISession
ように強制するにはどうすればよいでしょうか? SessionFactory
できません。また、簡単に判別できるセッション オブジェクトを作成することもできません。
上記のような場合、静的メソッドを完全に避けるのが最善です。
静的メソッドは単体テストできます。それらをモックすることはできません (一般に、 Molesのようにこれを行うフレームワークがいくつかあります。
静的メソッド/プロパティをモックすることはできません。したがって、classA
静的メンバーを使用する場合、単独でclassB
テストすることはできません。classA
更新: いくつかの静的クラスをオブジェクトにラップすることに問題はありません。時間はかかりませんが、システム内の結合を減らすことができます。
プログラミング言語に関係なくこの脅威を見つけますが、私の日常生活は PHP に関連しているため、PHP の静的メソッドを扱うための良いリソースは次のとおりですhttp://docs.mockery.io/en/latest/reference/public_static_properties.html