タグ付けされた質問 「stub」

8
広範囲にモックせずにユニットテストをどのように正確に記述する必要がありますか?
私が理解しているように、ユニットテストのポイントは、コードのユニットを単独でテストすることです。この意味は: コードベースの他の場所にある無関係なコードの変更によって壊れてはなりません。 統合テスト(ヒープで破損する可能性がある)とは対照的に、テストされたユニットのバグによって破損するユニットテストは1つだけです。 これはすべて、テストされたユニットのすべての外部依存関係をモックアウトする必要があることを意味します。そして、ネットワーク、ファイルシステム、データベースなどの「外部レイヤー」だけでなく、すべての外部依存関係を意味します。 これは、事実上すべての単体テストがモックする必要があるという論理的な結論につながります。一方、モックに関するGoogleの簡単な検索では、「モッキングはコードのにおい」であると主張する記事が数多くあり、ほとんど(完全にではありませんが)回避する必要があります。 さて、質問へ。 ユニットテストはどのように適切に書かれるべきですか? それらと統合テストの間の境界線は正確にどこにありますか? アップデート1 次の擬似コードを検討してください。 class Person { constructor(calculator) {} calculate(a, b) { const sum = this.calculator.add(a, b); // do some other stuff with the `sum` } } 依存関係Person.calculateをモックせずにメソッドをテストするテストCalculator(Calculator「外の世界」にアクセスしない軽量クラスであることを考えると)は、単体テストと見なすことができますか?


3
テスト対象のクラスの一部を偽造しても大丈夫ですか?
クラスがあるとしましょう(不自然な例とその悪いデザインを許してください): class MyProfit { public decimal GetNewYorkRevenue(); public decimal GetNewYorkExpenses(); public decimal GetNewYorkProfit(); public decimal GetMiamiRevenue(); public decimal GetMiamiExpenses(); public decimal GetMiamiProfit(); public bool BothCitiesProfitable(); } (GetxxxRevenue()およびGetxxxExpenses()メソッドには、スタブ化された依存関係があることに注意してください) 現在、GetNewYorkProfit()とGetMiamiProfit()に依存するBothCitiesProfitable()を単体テストしています。GetNewYorkProfit()とGetMiamiProfit()をスタブしても大丈夫ですか? そうしないと、GetNewYorkProfit()とGetMiamiProfit()をBothCitiesProfitable()と同時にテストしているようです。GetxxxProfit()メソッドが正しい値を返すように、GetxxxRevenue()およびGetxxxExpenses()のスタブを設定する必要があります。 これまでのところ、内部メソッドではなく外部クラスのスタブの依存関係の例を見てきました。 そして、それが大丈夫な場合、これを行うために使用すべき特定のパターンはありますか? 更新 コアの問題を見逃しているのではないかと心配しています。これはおそらく私の貧弱な例のせいです。基本的な質問は、クラス内のメソッドが、その同じクラス内で公開されている別のメソッドに依存している場合、その他のメソッドをスタブ化しても大丈夫(または推奨)ですか? たぶん何かが欠けているかもしれませんが、クラスを分割することが常に意味があるかどうかはわかりません。おそらく、もう1つの最小限の良い例は次のとおりです。 class Person { public string FirstName() public string LastName() public string FullName() } ここで、フルネームは次のように定義されます: public string …

4
モックはオープン/クローズの原則に違反しますか?
少し前に、私は見つけることができないStack Overflowの回答で、パブリックAPIをテストする必要があることを説明した文を読み、著者はインターフェイスをテストする必要があると言いました。また、メソッドの実装が変更された場合、テストケースを変更する必要はありません。これを行うと、テスト中のシステムが機能することを確認する契約が破られるため、著者は説明しました。つまり、メソッドが機能しない場合はテストが失敗しますが、実装が変更されたためではありません。 私たちがock笑について話すとき、これは私の注意を呼びました。モックはテスト対象システムの依存関係からの期待呼び出しに大きく依存しているため、モックはインターフェイスではなく実装と密接に結合されています。 モックとスタブの調査中、いくつかの記事は、依存関係からの期待に依存しないため、モックの代わりにスタブを使用する必要があることに同意しています。 私の質問は次のとおりです。 モックはオープン/クローズの原則に違反しますか? 最後の段落のスタブを支持する議論に欠けているものはありますか? もしそうなら、いつスモックを作成するのに適したユースケースになり、スタブを使用するのに適したユースケースになりますか?
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.