4

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

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

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

親愛なるゾアース、これについてあなたの意見は何ですか？

4

5 に答える 5

3

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

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

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

1つだけをテストするテストは、理解と保守が容易です。

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

テストカバレッジに夢中になる必要がありますか？

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

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

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

于 2009-10-22T12:09:18.400 に答える
2

私は同意します-私は振る舞いの検証よりも状態の検証に大きく傾くことに賛成です（テストダブルを使用しながら古典的なTDDの緩い解釈）。

『 The Art of Unit Testing』という本には、これらの分野で多くの優れたアドバイスがあります。

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

于 2009-10-21T17:12:40.893 に答える
1

これは、プログラムのドメインをどのようにモデル化するかによって異なります。

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

オブジェクトが連携するメッセージパッシング通信プロトコルの観点からドメインをモデル化する場合、プロトコルは重要であり、オブジェクトが役割を果たすプロトコルでの動作を調整するためにオブジェクトが格納するデータは、実装の詳細にすぎません。その場合、モックオブジェクトはジョブに適したツールであり、状態ベースのテストは、テストを重要でない実装の詳細に密接に結び付けます。

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

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

于 2009-10-21T17:25:50.103 に答える
1

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

于 2009-10-21T16:16:12.803 に答える
1

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

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

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

場合によっては、そうではないこともあります（これが、テストで収穫逓減のポイントの概念がある理由です）。

たとえば、本番環境に依存しないWebアプリを維持していて、アプリが壊れた場合に回避策がある（および/または簡単かつ即時のロールバックを実行できる）100人のユーザーがいる場合、そのアプリの完全なテストカバレッジに3か月を費やすのはおそらく無意味です。

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

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

于 2009-10-21T17:10:42.130 に答える