私は Microsoft Fakes を使用して、非常に長いメソッドを分析し、それをリファクタリングして、よりよく理解しています。別のプライベート メソッドにリファクタリングするのに適していると思われる行をいくつか分離しました。私が取っているアプローチは、変更による影響を最小限に抑えるために、コードを手動で変更しないことです (すぐに使用できるリファクタリングのみを使用します)。問題は次のとおりです。問題の行を別のプライベート メソッドにリファクタリングしたら、それらの行に関連付けられているすべてのセットアップ コード (およびそれらをラップする新しいプライベート メソッド) を削除し、それを「モック アウト」したいと思います。デフォルトの定型回答を提供して電話をかけます。これはスタブ/シムのようなにおいがしますが、テスト対象のクラスについて話しているので、「モックアウト」メソッドを除いてそのコードを実行するクラスが必要です。Rhino Mocks では、PartialMock を使用してそのような呼び出しをスタブ化します (最初に仮想化した後!!!) が、この状況で Fakes を使用できますか? ありがとう。
2 に答える
プライベート メソッド (モック プライベート メソッド) を上書きする場合は、shim を使用してこれを行います。
いくつかの良い読み物: http://adamprescott.net/2012/08/28/unit-testing-and-private-methods/ および http://adamprescott.net/2012/08/21/a-shim-ple-tutorial -with-microsoft-fakes/
この例には、プライベートなRead
内部呼び出しを行う public メソッドがあります...SecretMethod
var target = new FileReader("foo");
var shim = new ShimFileReader(target);
bool calledShimMethod = false;
shim.SecretMethod = () =>
{
calledShimMethod = true;
return "bar";
};
target.Read();
別の回答が述べたように、シムはこれを行う方法です。ただし、shim を使用することで、テストが public メソッドの実装に関連付けられることに注意してください。多くの場合、特に自分が書いていないコードをテストしている場合は、それについてできることは何もありません。実装をテストすると、コードが変更されたときにテストが壊れやすくなることを覚えておいてください。
そうは言っても、実装の詳細を回避して大量のセットアップを行うことができます。これはプラスであり、脆弱性の低いものに向かっている可能性があります。
私は取り組んでいるプロジェクトでシムをかなり使用していますが、私と同じように、シムは悪い設計のかなり良い指標であるため、必要になるたびに気分が悪くなるはずです。これを回避する最善の方法は、ストラテジー パターン (および一般的な DI) です。これにより、スタブに依存できるようになります。