unit-testing - どのくらいのテストで十分ですか？

Question

私は最近、統合テストを書く機能のコーディングに約 70% の時間を費やしました。ある時点で、私はこう考えていました。テストをざっと読んで、もう終わらせましょう…」</p>

5 分後、テストは失敗します。詳細な検査により、これは私たちが使用しているサードパーティライブラリの重要な未知のバグであることがわかりました。

では、何をテストし、何を信じるべきかについて、どこに線を引きますか? すべてをテストしますか、それともほとんどのバグが予想されるコードをテストしますか?

score 18 · Accepted Answer

私の意見では、テストに関しては実用的であることが重要です。失敗する可能性が最も高いこと、および/または失敗しないことが最も重要なこと (つまり、確率と結果を考慮に入れること) に対するテスト作業の優先順位を付けます。

コードカバレッジなどの 1 つの指標にやみくもに従うのではなく、考えてみてください。

テストスイートとコードに慣れたら終了します。(if?) 何かが失敗し始めたら、戻ってさらにテストを追加します。

score 4 · Accepted Answer

コードに中規模から大規模な変更を加えることを恐れなくなったら、十分なテストができている可能性があります。

score 3 · Accepted Answer

Gerald Weinberg の古典的な本 " The Psychology of Computer Programming"には、テストに関する良い話がたくさんあります。私が特に気に入っているのは、第 4 章「社会活動としてのプログラミング」です。「ビル」が同僚に自分のコードをレビューするように依頼したところ、わずか 13 個のステートメントで 17 個のバグが見つかりました。コードレビューは、バグを見つけるのに役立つ追加の目を提供します。目を使うほど、非常に微妙なバグを見つける可能性が高くなります。ライナスが言ったように、「十分な目玉があれば、すべてのバグは浅いものです」あなたのテストは基本的にロボットの目であり、昼夜を問わず何度でもコードを調べて、すべてがまだ適切かどうかを知らせてくれます。

十分なテストの数は、ゼロから開発するか、既存のシステムを維持するかによって異なります。

ゼロから始める場合、コード化できた機能の 10% が徹底的にテストされているため、テストの作成にすべての時間を費やして配信に失敗することは望ましくありません。ある程度の優先順位を付ける必要があります。1 つの例は、プライベートメソッドです。プライベートメソッドは、何らかの形式 (パブリック/パッケージ/保護) で表示されるコードで使用する必要があるため、プライベートメソッドは、より表示されるメソッドのテストでカバーされると見なすことができます。これは、プライベートコードに重要またはあいまいな動作またはエッジケースがある場合に、いくつかのホワイトボックステストを含める必要がある場所です。

テストは、1) 要件を理解していること、2) テスト容易性のためにコーディングすることで優れた設計手法を順守していること、3) 以前の既存のコードがいつ機能しなくなるかを確認するのに役立つはずです。ある機能のテストについて説明できない場合は、その機能を十分に理解していないため、問題なくコーディングできると断言できます。単体テストコードを使用すると、データベース接続やインスタンスファクトリなどの重要なものを引数として渡すなどのことを行う必要があり、クラスが単独でやりすぎて「神」オブジェクトになってしまうという誘惑に屈することはありません。コードをカナリアにするということは、より多くのコードを自由に記述できるということです。以前に合格したテストが失敗した場合、それは次の 2 つのいずれかを意味します。

既存のコードで作業する場合、次の変更要求またはバグ修正が行われたときに、しつこい心配をせずに、適切と思われるモジュールを自由に掘り下げることができるように、既知のすべてのシナリオがカバーされていることを示すことができるはずです。"何かを壊したらどうなるか」という問題が発生すると、実際にコードを変更するよりも、小さな修正でもテストに多くの時間を費やすことになります。

したがって、厳密で迅速なテスト数を提供することはできませんが、変更を加えたり機能を追加したりし続ける能力に対する自信を高めるカバレッジのレベルを狙う必要があります。 .

score 3 · Accepted Answer

良い質問！

まず、大規模な統合テストが功を奏したようです:)

私の個人的な経験から：

それが「グリーンフィールド」の新しいプロジェクトである場合は、厳密な単体テストを実施し、完全な (可能な限り完全な) 統合テスト計画を設計することを好みます。
テスト範囲が不十分な既存のソフトウェアの場合、特定の/既知の機能をテストする一連の統合テストを設計することを好みます。次に、コードベースをさらに進めながら、テスト (ユニット/統合) を紹介します。

どのくらいで十分ですか？難しい質問ですが、これで十分だとは思いません。

score 3 · Accepted Answer

「すべてが多すぎるだけで十分です。」

私は厳密な TDD の慣行に従っていません。すべてのコードパスをカバーし、重要だと思われるエッジケースを実行するのに十分な単体テストを作成するようにしています。基本的に、何がうまくいかないかを予測しようとします。また、書くテストコードの量を、テスト対象のコードがどれほどもろい、または重要であると考えているかに合わせようとします。

私は 1 つの分野で厳格です。バグが見つかった場合、まずバグを実行して失敗するテストを作成し、コードを変更して、テストが成功することを確認します。

score 1 · Accepted Answer

あなたまたはあなたのチームがメトリクスを追跡している場合、ソフトウェアのライフサイクルが進むにつれて、すべてのテストで見つかったバグの数を確認できます。テストに費やされた時間が発見されたバグの数を正当化しない許容可能なしきい値を定義した場合、それは停止すべきポイントです。

バグを 100% 見つけることはおそらくないでしょう。

score 0 · Accepted Answer

私は可能な限りユニットテストを行うことを好みます。最大の副作用の1つ（コードの品質を向上させ、いくつかのバグを防ぐのに役立つことを除く）は、私の意見では、単体テストの期待が高い場合は、コードの記述方法を改善する必要があります。少なくとも、それが私にとってうまくいった方法です。

私のクラスは、機能的でテスト可能になるように設計されているため、よりまとまりがあり、読みやすく、はるかに柔軟性があります。

そうは言っても、junitとcobertura（Javaの場合）を使用して、デフォルトで90％（ラインとブランチ）の単体テストカバレッジ要件を設定します。特定のクラスの性質（またはcoberturaのバグ）が原因でこれらの要件を満たすことができないと感じた場合は、例外を設けます。

単体テストはカバレッジから始まり、境界条件を現実的にテストするためにそれらを使用したときに実際に機能します。その目標をどのように実行するかについてのアドバイスについては、他のすべての答えが正しいです。

score 0 · Accepted Answer

この記事では、さまざまな数のユーザーを使用したユーザーテストの有効性に関する非常に興味深い洞察を提供します。これは、アプリケーションをテストしているユーザーが3人だけでエラーの約3分の2を見つけ、5人のユーザーでエラーの85％を見つけることができることを示しています。

単体テストでは、離散値を設定するのが困難です。覚えておくべき1つの提案は、単体テストは、テストしているコードを開発する方法についての考えを整理するのに役立つ可能性があるということです。コードの要件を記述し、それを確実にチェックする方法があれば、より迅速かつ確実に記述できます。

score 0 · Accepted Answer

開発者になる前は、QA で 1 年半働いていました。

すべてをテストすることはできません (単一のテキストボックスのすべての順列をトレーニングしたときに、既知の宇宙よりも時間がかかると言われました)。

開発者として、何をテストし、何をテストしないかの優先順位を知ったり述べたりすることは、あなたの責任ではありません。最終製品のテストと品質には責任がありますが、この責任を明確に与えられていない限り、機能の優先順位を明確に述べることができるのはクライアントだけです。QA チームがなく、わからない場合は、プロジェクトマネージャーに調べて優先順位を付けてもらいます。

テストはリスク軽減の演習であり、クライアント/ユーザーは何が重要で何が重要でないかを知ることができます。エクストリームプログラミングのテスト主導の開発を使用すると、適切なテストベースが得られ、変更後に回帰テストを行うことができます。

自然選択により、コードがテストに対して「免疫」になる可能性があることに注意することが重要です。Code Complete は、欠陥を修正してテストケースを作成し、同様の欠陥を探す場合、同様の欠陥のテストケースを作成することも良い考えであると述べています。

score 0 · Accepted Answer

私はすべてをテストします。私はそれが嫌いですが、それは私の仕事の重要な部分です.

score 0 · Accepted Answer

I spend a lot of time on unit tests, but very little on integration tests. Unit tests allow me to build out a feature in a structure way. And now you have some nice documentation and regression tests that can be run every build

Integration tests are a different matter. They are difficult to maintain and by definition integrate a lot of different pieces of functionality, often with infrastructure that is difficult to work with.

score 0 · Accepted Answer

人生のすべてと同様に、それは時間とリソースによって制限され、その重要性に関連しています。理想的には、壊れる可能性があると合理的に考えられるものすべてをテストします。もちろん、見積もりが間違っている可能性もありますが、想定が正しいことを確認するための過剰テストは、バグがどれほど重大であるかと、次の機能/リリース/プロジェクトに進む必要があるかどうかによって異なります。

注: 私の回答は、主に統合テストに対応しています。TDDは非常に異なります。以前に SO でカバーされていましたが、追加する機能がなくなったらテストを中止します。TDD は設計に関するものであり、バグの発見ではありません。

unit-testing - どのくらいのテストで十分ですか？

12 に答える 12

Related

Reference