モックフレームワークと高いテストカバレッジは重要ですか？

Question

モックフレームワーク、例EasyMock、ダミーの依存関係のプラグインを簡単にします。そうは言っても、特定のコンポーネントで異なるメソッドがどのように呼び出されるか（およびその順序）を確認するためにそれらを使用することは、私には悪いようです。動作をテストクラスに公開するため、運用コードの維持が難しくなります。そして、私は本当に利点を見ていません。精神的には、重いボールにつながれているように感じます。

単にインターフェイスに対してテストし、テストデータを入力として提供し、結果をアサートしたいです。さらに良いのは、特定のプロパティを検証するためにテストデータを自動的に生成するテストツールを使用することです。例えば1つの要素をリストに追加し、すぐに削除すると同じリストが生成されます。

職場では、テスト範囲を提供するハドソンを使用しています。残念ながら、すべてがテストされていることに盲目的に取り付かれやすくなります。メンテナンスモードでも生産性を上げたい場合は、すべてをテストすべきではないと強く感じています。 1つの良い例は、Webフレームワークのコントローラーです。一般に、ロジックはほとんど含まれていないはずなので、コントローラーがそのようなメソッドや特定の順序でメソッドを呼び出すモックフレームワークを使用したテストは、私の意見では無意味です。

親愛なる皆さん、これについてどう思いますか？

Answer 1

プログラムのドメインをどのようにモデル化するかによります。

あるデータ構造からデータを読み取り、派生データを別のデータ構造に保存するデータ構造とメソッドに保存されたデータに関してドメインをモデル化する場合（手順または機能はデザインの手順または機能に応じて）、モックオブジェクト適切ではありません。いわゆる「状態ベース」テストはあなたが望むものです。気になる結果は、プロシージャが適切なデータを適切な変数に入れ、それを実現するために呼び出すものが実装の詳細にすぎないことです。

オブジェクトが連携するメッセージ受け渡し通信プロトコルに関してドメインをモデル化する場合、プロトコルは重要であり、オブジェクトが役割を果たしているプロトコルでの動作を調整するためにオブジェクトが保存するデータです詳細。その場合、モックオブジェクトはジョブおよび状態ベースのテストに適切なツールであり、テストを重要でない実装の詳細に結び付けすぎます。

そして、ほとんどのオブジェクト指向プログラムには、さまざまなスタイルがあります。一部のコードは純粋に機能的に記述され、不変のデータ構造を変換します。他のコードは、非表示の内部状態を経時的に変更するオブジェクトの動作を調整します。

高いテストカバレッジに関しては、それほど多くはわかりません。テストカバレッジが低いと、テストが不十分な場所がわかりますが、テストカバレッジが高いと、コードが適切にテストされていることがわかりません。たとえば、テストはコードパスを介して実行できるため、カバレッジの統計情報を増やすことができますが、実際にはそれらのコードパスが何をしたかについては断言できません。また、実際に重要なのは、プログラムのさまざまな部分がどのように組み合わされて動作するかであり、単体テストのカバレッジではわかりません。テストが実際にシステムの動作を適切にテストしていることを確認したい場合は、ミューテーションテストツールを使用できます。遅いプロセスなので、チェックインごとではなく、ナイトリービルドで実行します。

Answer 2

2つの質問を読みました：

コンポーネントの特定のメソッドが特定の順序で呼び出されることをテストすることについて、あなたはどう思いますか？

過去にこれに反則しました。さらに多くの「スタブ」を使用します「モッキング」が大幅に減りました。最近。 1つのことだけをテストする単体テストを作成しようとしています。これを行うと、通常、スタブアウトする非常に簡単なテストを書くことができます 他のほとんどのコンポーネントとの相互作用。また、順序付けを行うことはほとんどありません。これにより、テストの脆弱性が軽減されます。

1つのことだけをテストするテストは、理解と保守が簡単です。

また、多くのコンポーネントとの相互作用に対して多くの期待を書かなければならない場合、とにかくテストしているコードに問題がある可能性があります。テストを維持するのが難しい場合、テストしているコードはしばしばリファクタリングできます。

テストカバレッジに取りつかれるべきですか？

特定のクラスの単体テストを書くとき、テストカバレッジにかなり夢中になります。これにより、テストしていない重要な動作を簡単に見つけることができます。また、どのビットをカバーする必要がないかについて判断することもできます。

全体的なユニットテストのカバレッジの統計情報彼らが高い限り、特に興味はありません。

システム全体の100％の単体テストカバレッジ？まったく興味がない。

Answer 3

同意する-動作検証よりも状態検証に重点を置くことに賛成です（従来のTDD をテストダブルを使用しながら）。

本ユニットテストの技術には、これらの領域に関する十分なアドバイスがあります。

100％のテストカバレッジ、GUIテスト、ゲッター/セッターまたはその他の非論理コードのテストなどは、優れたROIを提供する可能性が低いようです。 TDDは、どのような場合でも高いテスト範囲を提供します。何が壊れるかをテストします。

Answer 4

同様の質問をしたユニットテストの量良いこと。これは、人々が適切だと感じるさまざまなレベルのテストのアイデアを提供するのに役立つかもしれません。

Answer 5

1. コードのメンテナンス中に、一部の若い従業員が「コントローラー呼び出しなど、特定の順序でそのようなメソッドを実行」するコードの一部を壊す可能性はどのくらいですか？

2. このような事態が発生した場合、組織のコストはいくらですか？実稼働停止、デバッグ/修正/再テスト/再リリース、法的/財務リスク、評判リスクなど...

今、＃1と＃2を掛けて、妥当な量のテストカバレッジを達成することに抵抗があるかどうか、リスクに見合うかどうかを確認します。

そうでない場合もあります（これが、テストで利益が減少するという概念がある理由です）。

E.g。実稼働上重要ではなく、アプリが壊れた場合に回避策を講じる（および/または簡単かつ即時にロールバックできる）100人のユーザーがいるWebアプリを維持する場合、そのアプリの完全なテストカバレッジを3か月費やすことはおそらく非-sensical。

小さなバグが数百万ドル以上の結果をもたらす可能性のあるアプリ（スペースシャトルソフトウェア、または巡航ミサイルの誘導システムなど）で作業している場合、完全なカバレッジでの徹底的なテストははるかに意味があります。

また、私はあなたの質問を読みすぎているかどうかはわかりませんが、モック対応の単体テストがアプリケーション/統合機能テストを何らかの形で除外していることを暗示しているようです。その場合、そのような概念に反対する権利があります。2つのテストアプローチが共存する必要があります。