壊れた古い/レガシーの単体テスト
私は大企業で働いており、数千のjunitテストを含む大規模なJavaアプリケーションを担当しています。この役割に移行して以来、200-300のテストが失敗しました（テストは古くて壊れやすく、通常はライブサンドボックスデータで終わるスパゲッティ依存関係の混乱です。
私の目標は、100％テストに合格することです。これにより、単体テストの失敗時にビルドを中断できますが、壊れたテストに対処するまで、ビルドを中断することはできません。メンテナンスの予算は主にサポート用であるため、予算はほとんどありませんが、私のチームはぶつからないフルーツテスト（主に構成/ローカルリソースの問題）を特定して修正し、実際には醜いテストを30〜40に減らしています。
ベストプラクティスについての意見を教えてください。テストは価値があるとは思いませんが、何をテストしているのか、また掘り下げないとうまくいかない理由もわかりません。これには、おそらく時間と費用がかかりません。
壊れたテストのステータスを私たちが知っているすべてのもので文書化し、壊れたテストを完全に削除または無視して、優先度の低いバグ/作業項目を入力して調査および修正する必要があると思います。その後、100％になり、他のテストから真の価値を引き出し始めます。メンテナンス/リファクタリングのウィンドフォールがあれば、それらを再び拾うことができます。
最善のアプローチは何でしょうか？
編集：これは この質問 とは別の質問だと思います。これから作成するテストには明確な方向性があるので、現在の大規模なセットの前に対処するためにレガシーの失敗したテストを継承しましたテストが意味を持つようになります。
私がやろうとしていることは、まず失敗し、常に失敗しているテストを無効にすることです。
テストが失敗するようにしてください。
調査すると、会社に長く滞在している人にそれらについて尋ねることができるかもしれませんが、文書化/キャプチャできるそれらについての部族の知識がたくさんあるかもしれません。多分あなたのVCSログから。 「ああ、Xにアップグレードして以来、そのテストは常に失敗している」などの情報が役立つ場合があります。
テストする機能が何であるかがわかったら、次のことを決定できます。
- テストされていることを気にしますか
- これをテストすることがどれほど重要か
そして、優先順位リストを作成します。
おそらく何年もの間無視されてきたので、このリストの何も後でもっと時間を稼ぐのに十分重要ではないようです。したがって、私はtoo多くの時間/リソースを費やして、これらすべての壊れたテストの文書化と分析を行いません。
私は次のようにします：
失敗したテストが検証しようとしているものを正確に特定しようとします。
トリアージ-一部のテストが世界の（古い）状態のような重要でないものをテストしようとしている場合は、それらを削除します。重要なものを検証しようとしていることに気づいた場合は、それらのテストが正しく実行されているかどうかを確認してください。正しくテストされていない場合は、正しくテストしてください。
良いテストができたので、プロダクションコードの問題を修正します。
会計を覚えておいてください。コードのすべての行は負債ですが、資産として誤って評価される可能性があります。の delete キーはあなたの会社に多くの価値を生み出すことができます。
200-300の壊れたテスト（何年も壊れそうです）。
痛い！私はかつて同様の状況に直面しましたが、「常に厳しい」メンタリティのために何ヶ月も失敗したという事実をチームが無視し始めたような7つのテストが失敗しました。
私の目標は、100％テストに合格することです。これにより、単体テストの失敗時にビルドを中断できますが、壊れたテストに対処するまで、ビルドを中断することはできません。
チームのジュニア開発者であるにも関わらず、同様の目標に取り憑かれていました。何ヶ月にもわたって失敗するテストが山積みになっていることに気付いていたからです。私はそれらを「警告」からビルドエラーに変えたいと思っていました（おそらくチームの他のメンバーにはやや不愉快なことです）。
壊れたテストのステータスを私たちが知っているすべてのもので文書化し、壊れたテストを完全に削除または無視して、優先度の低いバグ/作業項目を入力して調査および修正する必要があると思います。その後、100％になり、他のテストから真の価値を引き出し始めます。メンテナンス/リファクタリングのウィンドフォールがあれば、それらを再び拾うことができます。
これらも私の考えです。これらの障害のあるテストをすべて一時的に無効にして、ゆっくりとアクセスし、時間をかけて修正することができます。たとえそれらが非常に重要であると考えている場合でも、優先度が低くても、これらの修正をスケジュールすることは重要です。なぜなら、そのようなアイテムは簡単に修正されないためです。私にとっての優先事項は、失敗した新しいテストが導入されないようにすることです。
あらゆる種類の警告と同様に、ビルドを壊さない場合、それらはすぐに蓄積される傾向があります。これは、警告（この場合は失敗したテスト）を無視する習慣がすぐに導入される警告を増やし、それらの警告をゼロに維持するという誘惑を減らすことができるような、チームのダイナミックを想定しています。
非常に良心的なチームはこれらの問題に悩まされず、新しい警告（テストでの新しい失敗）の導入を回避するかもしれませんが、これらをエラーに変えることでもう少し強引な予防戦略を実行する方が間違いなく安全です必須マージプロセスの前に修正されます。
ですから、私の提案はあなたの提案と同じです（ただし、強い意見だけですが、おそらくこれを指標とより科学的な答えで裏付けることができます）。これらの古いテストを無効にして、最終的に修正するためにスケジュールに入れます。最優先事項は、現在成功しているテストが失敗し始めても最終的に無視されないようにすることで、この問題が積み重なって悪化しないようにすることです。
ある意味であなたは幸運です。テストに合格し、テストに合格し、テストに合格してはならない（セキュリティに誤解を与える）よりも、テストに不合格でなくてはならない（少なくとも何かが間違っていることを警告する）方がよい。
もちろん前者がいる場合、後者もある可能性が非常に高いです（したがって、テストはパスしますが失敗するはずです）。
すでに述べたように、今のところ、失敗したテストを無効にしますが、テストログにメッセージを常に通知するようにメッセージを出力させます。
しかし、合格したテストとそうでないテストを見つけて除外するために、テストスイート全体を調べるためのリソースを必ず見つける必要があります。これらのそれぞれは、コードにバグがあることを意味します現在、テストサイクルで検出されていません。
コードベースにぶら下がっている暗い雲を使用すると、テストを正しく実行し、いくつかのテストを検討する必要があると彼らに伝えるだけでなく、テストの完全なレビューにいくらかの予算を確保できる可能性があります。失敗するはずがないときに失敗したように見えるが、テストがコード内のエラーを適切に検出していることを信頼していないため、テストセットがその仕事を信頼できないためです。
以前の会社でそれを行ったとき、私はそのようなレビューのために働いていましたが、何百ものテストがコードがすべきことについて誤った仮定で書かれており、コードにつながることがわかりました（これは同じ誤った仮定を使用して書かれました） ）本来あるべきではないときにテストに合格した。これを修正することで、多くの厄介なコーナーケースバグが解決されました（ほとんどは重要ではありませんでしたが）、いくつかの重要なシステムがダウンした可能性があります。
単体テストに失敗すると、ビルドが壊れます。それを実現し、その目標を設定してくれてありがとう。人間の心は 永続的な誤警報 の発生源よりも完全に無視することはほとんどできません。
これらのテストを捨て、振り返ってはいけません。それらが何年も失敗していて、今までに対処されていない場合、それらは優先事項ではありません。
部族の知識については、部族の知識を持つ人々がまだそこにいるのであれば、彼らは今までに失敗したテストを修正しているはずです。そうでない場合は、これらも優先事項ではありません。
部族の知識がない場合、あなたとあなたのチームはロジックの所有権を取得する必要があります。失敗したテストは、役立つよりも誤解を招く可能性があります-世界は進んでいる可能性があります。
関連性のある新しいテストを作成し、優れたコードを書き続けます。