12

ユニットテストがすべて必要であるか重要であることに同意しなかった私のリード開発者とちょうど会話をしました。彼の見解では、内部リファクタリング（インターフェースの変更など）によってテストを書き直したり、見直したりする必要がなくなるため、コードカバレッジが十分に高い機能テストで十分です。

説明してみましたが、あまり遠くまで行かなかったので、もっと上手くやれると思いました。;-） それで...

機能テストが提供しない単体テストコードのいくつかの正当な理由は何ですか？あなたが持っているのが機能テストだけだとしたら、どんな危険がありますか？

編集＃1すべての素晴らしい答えをありがとう。機能テストとは、製品全体のテストだけでなく、製品内のモジュールのテストでもあり、必要に応じてモックを使用した単体テストの低レベルではないことを付け加えたいと思います。機能テストは自動で継続的に実行されますが、単体テストよりも時間がかかります（これは単体テストの大きな利点の1つです）。

私はレンガと家の例が好きです。私のリード開発者が言っているのは、家の壁をテストするだけで十分だと思います。個々のレンガをテストする必要はありません... :-)

4

8 に答える 8

17

頭のてっぺんから

  • ユニットテストは、労力をかけずに繰り返すことができます。一度書けば、何千回も実行でき、人的労力は必要なく、機能テストから得られるよりもはるかに高速なフィードバックが得られます。
  • ユニットテストは小さなユニットをテストするので、エラーが発生する正しい「セクター」をすぐに指し示します。機能テストはエラーを指摘しますが、それらは協力している場合でも、多くのモジュールによって引き起こされる可能性があります。
  • インターフェイスの変更を「内部リファクタリング」と呼ぶことはほとんどありません。インターフェイスの変更は多くのコードを壊す傾向があり、（私の意見では）新しいテストループを強制します。
于 2008-10-08T11:52:40.460 に答える
10

単体テストは、開発者がコードが失敗した場所を確認するためのものです

機能テストは、コードが要求どおりに動作するかどうかをビジネスが確認するためのものです

于 2008-10-08T12:02:11.423 に答える
6

単体テストは、開発者がコードが失敗した場所を確認するためのものです

機能テストは、コードが要求どおりに動作するかどうかをビジネスが確認するためのものです

単体テストは、レンガが正しく製造されていることを確認しています

機能テストは、家が顧客のニーズを満たしていることを確認しています。

それらは別のものですが、前者が実行された場合、後者ははるかに簡単になります.

于 2008-10-08T12:13:17.033 に答える
4

毎回コードベース全体を効果的にテストしているため、機能テストが失敗した場合、問題の原因を見つけるのははるかに困難になる可能性があります。対照的に、単体テストは潜在的な問題領域を区分化します。他のすべての単体テストが成功したが、これが成功した場合、問題はテストしているコードにあり、他の場所にはないことが保証されます。

于 2008-10-08T11:53:29.460 に答える
1

バグは開発サイクルでできるだけ早く発見する必要があります。バグが設計からコード、またはコードからテスト、または (できればそうではないが) テストから本番環境に移動すると、修正に必要なコストと時間が増加します。

当店はそれだけの理由でユニットテストを実施しています（他にも理由があると思いますが、私たちにとってはそれで十分です）。

于 2008-10-08T12:00:44.313 に答える
0

TDD / BDDでは、プログラムを作成するために単体テストが必要です。プロセスは進みます

テストに失敗->コード->テストに合格->リファクタリング->繰り返し

リンクされた記事には、TDD/BDDの利点についても言及されています。要約すれば：

  • デバッガーの使用を排除することに非常に近づいています（私は現在テストでのみ使用しており、それらの場合はめったに使用しません）
  • コードは数分以上乱雑にとどまることができません
  • APIビルトインのドキュメント例
  • 緩い結合を強制します

リンクにはTDD/BDDの（ばかげた）ウォークスルーの例もありますが、PowerPoint（ew）にあるので、ここにhtmlバージョンがあります。

于 2013-03-03T22:23:32.207 に答える
0

純粋なエクストリームプログラミング/アジャイル開発手法を使用する場合、単体テストは開発の要件であるため、常に必要です。

純粋なXP/アジャイルでは、アプリケーションに対して実行されるテストに基づいてすべての要件を作成します

  • 機能テスト-機能要件を生成します。
  • 単体テスト-関数またはオブジェクト要件を生成します。

それ以外に、単体テストを使用して、機能要件を永続的に追跡できます。

つまり、関数の動作方法を変更する必要があるが、入力フィールドと出力は変更されないままである場合。次に、テストを実行するだけでよいので、ユニットテストは起こりうる問題を追跡し続けるための最良の方法です。

于 2008-10-08T12:19:17.647 に答える
0

考えられるすべてのユースケースをチェックする機能テストの完全なセットがすでにあり、単体テストの追加を検討していると仮定します。機能テストは考えられるすべてのバグをキャッチするため、単体テストはバグのキャッチには役立ちません。ただし、単体テスト、統合テスト、および機能テストの組み合わせと比較して、機能テストのみを使用することにはいくつかのトレードオフがあります。

  • 単体テストはより高速に実行されます。テスト スイートの実行に何時間もかかる大規模なプロジェクトに携わったことがある場合は、高速なテストが重要である理由を理解できます。
  • 私の経験では、実際に言えば、機能テストは不安定になる可能性が高くなります。たとえば、ヘッドレス capybara-webkit ブラウザーが何らかの理由でテスト サーバーにアクセスできない場合がありますが、再実行すると正常に動作します。
  • 単体テストはデバッグが容易です。単体テストでバグが見つかったと仮定すると、問題がどこにあるかを正確に特定することがより簡単かつ迅速になります。

一方、機能テストのみを保持し、単体テストを追加しないことにしたとします。

  • システム全体を再構築する必要が生じた場合でも、テストを書き直す必要はないかもしれません。単体テストがあった場合、それらの多くはおそらく削除または書き直されます。
  • システム全体を再構築する必要が生じた場合でも、回帰について心配する必要はありません。まれなケースをカバーするために単体テストに依存していたが、それらの単体テストを削除または書き直すことを余儀なくされた場合、新しい単体テストは古い単体テストよりも間違いを含む可能性が高くなります。
  • 機能テスト環境をセットアップし、学習曲線を乗り越えたら、単体テスト、統合テスト、および機能テストを組み合わせて作成するよりも、追加の機能テストを作成する方が簡単で、正しく作成する方が簡単な場合がよくあります。
于 2013-11-27T05:11:43.970 に答える