人々はどのようにして彼らのテストスイートを維持しますか？
特に、私は次の点に興味があります。
テストケースが間違っている（または古くなっている）ため、修復（または破棄）する必要があることをどのようにして知っていますか？つまり、テストケースが無効になったとしても、テストケースが通過して沈黙する可能性があるため、ソフトウェアが正常に動作していると誤って信じる可能性があります。では、テストスイートのこのような問題をどのようにして実現するのでしょうか。
テストスイートが十分ではなく、新しいテストケースを追加する必要があることをどのようにして確認しますか？これは要件の変更と関係があると思いますが、テストスイートの妥当性をチェックするための体系的なアプローチはありますか？
短い答え：次のコードカバレッジやコード品質ツールなど、テストケースの品質を維持するのに役立つ既知のツールを使用します。Cobertura、PMD、Sonarなど、プログラムの重要なコンポーネントが十分にテストされていない場合に気付くのに役立ちます。また、統合テストを記述します。これは、何か問題が発生したときに最初に壊れる可能性が最も高いテストです。
長い答え：
テストケースが間違っている（または古くなっている）ため、修復（または破棄）する必要があることをどのようにして知っていますか？つまり、テストケースが無効になったとしても、テストケースが通過して沈黙する可能性があるため、ソフトウェアが正常に動作していると誤って信じる可能性があります。では、テストスイートのこのような問題をどのようにして実現するのでしょうか。
- Cobertura などのコードカバレッジツールを使用すると、特定のクラスまたは複雑なメソッドのテストケースでは不十分であることを検出できます。どこでも100％のコードカバレッジに到達する必要はありません。ほとんどの場合、達成するのは難しく、必ずしも有用ではありません。ただし、プログラムの最も重要な側面のテストは、コードカバレッジの少なくとも80％を目標として維持する必要があります。
- 継続的なビルドおよび統合ツール、たとえば私が非常に気に入っている Jenkins などを組み合わせて使用する Sonar プラグインを使用すると、最新の変更の責任者に電子メールやその他のタイプのアラートを送信するトリガーを設定できます。さまざまなグラフと統計情報（Sonarは他の多くのツールの中でCoberturaも使用しています）は、コードレビュー担当者とテストケース開発者が重要なことに集中するのに役立ちます。
テストスイートがもはや十分ではなく、新しいテストケースを追加する必要があることをどのようにして知っていますか？これは要件の変更と関係があると思いますが、テストスイートの妥当性をチェックするための体系的なアプローチはありますか？
最初の質問に対して私が書いたのは、2番目の質問に対する回答の一部です。ここに次の点も追加します。
- テストケースに加えて、統合テストケース（または、必要に応じて「ビジネス」ケース）を記述します。これらは多くの場合、複数のクラス/メソッドに依存しているため、最初に変更/破損する可能性が高くなります。そして、彼らは頻繁に壊れるので、それが忘れられることはほとんどありません。私の個人的な経験から、優れたテストの作成に役立つ唯一のアプローチ/方法論は、 テスト駆動開発 です。特に、テストケースを書いている人が、そのコードを書いている人と同じではない場合。 TDDを使用して適切なテストケースを作成することにも時間がかかりますが、少なくとも私にとっては、結果は非常に満足できるものでした。
- バグが出たときはいつでも、修正とそれに付属するテストケースを書いてください。テストケースは、この特定のバグのみをカバーする必要があります。バグの原因となるコードを完全にカバーしたので、それが再び出てくることはありません。
sureテストケースを正しく作成する方法はありません。ただし、要件を理解し、コードを理解し、同意することを確認することで、テストケースを作成するときに集中できます。テストスイートを使用することのポイントは、これを一度だけ実行する必要があり、それ以降はテストを再実行してテストが成功することを確認するだけですが、テストスイートがないと、本当に集中する必要があります常時、つまり、コードベースに対して何かをするときはいつでも。しかし、そもそも正しいことをしていることを確認しなければならないという根本的な問題は残っています。コンピュータは、その仕事から私たちを解放するのに十分にインテリジェントではありません。
したがって、（1）テストスイートが不完全な場合、それを確認する簡単な方法はありません。コードカバレッジ分析は、一部のコード行が実行されないことを証明できます。つまり、スイートには何らかの欠陥がありますが、その欠陥の程度は深刻ではなく、十分であることを証明することはできません。 100％のコードカバレッジを使用しても、システムの関連するすべてのstatesが実行される保証はありません。存在する可能性のある状態の組み合わせの数のため、現実的なシステムでは完全な状態カバレッジは実現できません。テストケースが少なくともチェック対象のチェックに対して正しいことを確認するための1つの優れた手法は、テストを記述し、テストが実際に失敗することを確認し、コードを作成または変更して、テストが成功することを確認することです。したがって、テスト駆動開発の熱意：個々のテストが正しいことを確実に行うことができ、コードベース全体をそのように作成すれば、大規模システムでも同様のレベルの信頼を得ることができます。
（2）テストスイートは通常不十分になりますいつでも要件が変更されます-推測する必要はありません。顧客が特定の動作の変更を望んでいて、変更の前と後の両方でテストが成功する場合、その特定の入出力関係を実行していないことは明らかです。
テストカバレッジがない、またはカバレッジがわからないレガシーシステムについては、正式な証拠はありませんが、（親の助言：個人的な意見が続きます）経験から言うと、テストは圧倒的に可能性が高いですnotで十分です。テストが事後の、オプションの、品質を向上させるが、それほど必要ではないアクティビティと見なされる場合、テストがコードベースに遅れないようにするインセンティブがないため、テストは不完全で体系的でない傾向があります。ありません。