私は、単体テストの回帰問題の処理に多くの時間を費やしているソフトウェア開発チーム (私の場合は約 30% の時間です!!!) のための何らかの解決策を探していました。日基準。
以下は、私がよく知っている 1 つのソリューションで、特定の単体テストが失敗した原因となった最新のコード変更を分析します。
ベンチマークできるように、同様のツールを知っている人がいるかどうかを知りたかったのです。同様に、誰かがこの厄介な問題を処理するための別のアプローチを推奨できる場合.
アドバンスに感謝
質問する
191 次
3 に答える
3
お見舞い申し上げます。もろいテスト症候群のようですね。理想的には、単体テストへの1回の変更は、1回のテストを中断するだけであり、それは実際の問題であるはずです。私が言ったように、「理想的には」。しかし、この種の行動は一般的で治療可能です。
チームと一緒に時間をかけて、これらすべてのテストが失敗する理由の根本原因分析を行うことをお勧めします。うん、どのテストが最も頻繁に失敗し、どのテストが一緒に失敗するかを追跡するいくつかの素晴らしいツールがあります。一部の継続的インテグレーションサーバーにはこれが組み込まれています。それは素晴らしいことです。でも、お互いに聞いてみればわかると思います。私はこれを経験してきましたが、チームは常に彼らの経験から知っています。
とにかく、これを引き起こす私が見た他のいくつかのこと：
- 単体テストは通常、テストしているクラスとメソッド以外に依存するべきではありません。忍び込んだ依存関係を探します。テストを容易にするために、依存性注入を使用していることを確認してください。
- これらは本当にユニークなテストですか？それとも、同じことを何度もテストしていますか？それらが常に一緒に失敗する場合は、1つを除いてすべてを削除しないのはなぜですか？
- 多くの人々は、単体テストよりも統合を好みます。なぜなら、彼らは自分たちの支出に対してより多くのカバレッジを得るからです。しかし、これらを使用すると、1回の変更で多くのテストが失敗する可能性があります。多分あなたは統合テストを書いていますか？
- おそらく、それらはすべて、多くのテストのためのいくつかの一般的なセットアップコードを実行しているため、一斉に壊れてしまいます。たぶん、これは振る舞いを分離するためにモックアウトすることができます。
于 2010-09-22T07:41:41.173 に答える
2
- 失敗する可能性が最も高いテストのサブセットの実行に関して - 通常、他のチームメンバーが原因で失敗するため (少なくとも私の場合)、他の人にテストを実行するよう依頼する必要があります - これは開発の一部で「政治的に問題がある」可能性があります環境;)。他の提案は評価されます。どうもありがとう
テストを実行するために「他の人に依頼」する必要がある場合は、テスト インフラストラクチャに深刻な問題があることを示唆しています。すべてのテストは (誰が書いたかに関係なく) 自動的に実行されるべきです。失敗したテストを修正する責任は、テストの作成者ではなく、変更をコミットした人にあるべきです。
于 2011-01-18T12:04:22.093 に答える
2
頻繁にテストし、頻繁にコミットします。
まだ行っていない場合は、継続的インテグレーションツールを使用し、コミットする前に自動テストを実行するように開発者に依頼/要求することをお勧めします。テストの少なくともサブセット。すべてのテストの実行に時間がかかりすぎる場合は、コミットごとにビルド (すべての自動テストの実行を含む) を生成する CI ツールを使用して、どのコミットがビルドを中断したかを簡単に確認できるようにします。
自動化されたテストが脆弱すぎる場合は、機能をテストせずに実装の詳細をテストする可能性がありますか? 実装の詳細をテストするのが良い場合もありますが、問題が発生する可能性があります。
于 2010-09-22T07:20:13.143 に答える