壊れた古い/レガシーユニットテスト

私は大企業で働いており、何千ものJUnitテストがある大規模なJavaアプリケーションを担当しています。私がこの役割に移行して以来、200〜300のテストが壊れています（何年も壊れている可能性があります）。テストは古くて壊れやすく、通常はライブサンドボックスデータで終わるスパゲッティの依存関係の混乱です。

私の目標はテストを100％合格することで、単体テストの失敗でビルドを中断できますが、失敗したテストに対処するまではできません。メンテナンス予算は主にサポートのためであるため、予算はほとんどありませんが、私のチームは、問題の少ないフルーツテスト（主に構成/ローカルリソースの問題）を特定して修正しました。

ベストプラクティスに関する意見はありますか？テストは価値があるとは思いませんが、テストしているものが何なのか、掘り下げなければ動作しない理由もわかりません。おそらく時間とお金がかかるでしょう。

壊れたテストのステータスを既知のもので文書化し、壊れたテストを完全に削除または無視し、優先順位の低いバグ/作業項目を入力して調査および修正する必要があると考えています。その後、100％になり、他のテストから真の価値を引き出し始めます。メンテナンス/リファクタリングの失敗があれば、それらを再び拾い上げることができます。

最善のアプローチは何でしょうか？

編集：これはこの質問とは異なる質問だと思います。なぜなら、今後書くべきテストの明確な方向性があるからです。しかし、現在の大規模なテストセットが意味を持つようになる前に対処するために、レガシーの失敗したテストを継承しました。

私がすることは、最初に失敗して常に失敗するテストを無効にすることです。

テストの失敗が問題になるようにします。

調査すると、あなたの会社に長く住んでいる人に彼らについて尋ねることができるかもしれません。彼らについての多くの部族の知識があるかもしれません。たぶん、VCSログから。「ああ、Xにアップグレードしたので、そのテストは常に失敗しました」または他の情報が役立つ場合があります。

テストされている機能が何であるかがわかったら、次のことを判断できます。

• これがテストされていることを気にしますか
• これをテストすることの重要性

そして、優先リストを作成します。

このリストには何年も既に無視されているので、後でより多くの時間を得るのに十分な重要性はありません。そのため、これらすべての壊れたテストの文書化と分析に時間/リソースを費やすことはあまりありません。

私は次のことをします：

1. 失敗したテストが検証しようとしているものを正確に判断しようとします。

2. トリアージ-いくつかのテストが（古い）世界の状態のような重要でないものをテストしようとしている場合、それらを削除します。それらのいくつかが重要な何かを検証しようとしていることに気付いたら、それらのテストが正しく実行しているかどうかを判断してください。正しくテストされていない場合は、正しくテストしてください。

3. 良いテストができたので、本番コードの問題を修正します。

アカウンティングを覚えておいてください。すべてのコード行は負債ですが、資産として誤って評価される可能性があります。deleteキーは、あなたの会社のための価値の多くを作成することができます。

200〜300の壊れたテスト（おそらく壊れている可能性があります）。

痛い！私は同様の状況に一度直面しましたが、チームが「常にクランチ」メンタリティのために数か月間失敗したという事実を無視し始めたところ、7つのテストが失敗しました。

私の目標はテストを100％合格することで、単体テストの失敗でビルドを中断できますが、失敗したテストに対処するまではできません。

私はチームのジュニア開発者でしかありませんでしたが、数か月にわたってより多くのテストが失敗する山積みに気付いていたので、私は同様の目標に取りつかれていました。私は、それらを「警告」からビルドエラーに変換することを望んでいました（おそらく、チームの他のメンバーにとってはやや厄介なことです）。

壊れたテストのステータスを既知のもので文書化し、壊れたテストを完全に削除または無視し、優先度の低いバグ/作業項目を入力して調査および修正する必要があると考えています。その後、100％になり、他のテストから真の価値を引き出し始めます。メンテナンス/リファクタリングの失敗があれば、再びそれらを拾うことができます。

これらも私の考えです。これらの障害のあるテストをすべて一時的に無効にし、ゆっくりとアクセスして、時間をかけて修正することができます。ただし、優先度が低い場合でも、本当に重要だと思う場合は、修正をスケジュールすることが重要です。なぜなら、そのようなアイテムは簡単に修正されないためです。私にとっての優先事項は、失敗する新しいテストが導入されないようにすることです。

あらゆる種類の警告と同様に、ビルドを壊さないと、すぐに積み重なる傾向があります。これは、警告（この場合はテストに失敗した）を無視する習慣がすぐに多くの警告を導入し、それらの警告をゼロに維持する誘惑を減らすことができるようなチームダイナミックを想定しています。

非常に良心的なチームは、これらの問題と回避新しい警告（テストで新しい障害）の導入を受けていないかもしれないが、それはもう少し強引に行くとエラーことにこれらを回すことによって予防戦略を行使することは間違いなく安全です必見前にAに固定しますマージプロセス。

したがって、私の提案はあなたのものと同じです（強い意見だけではありますが、多分、メトリックとより科学的な答えでこれをバックアップできるかもしれません）。これらの古いテストを無効にし、最終的に修正するためにスケジュールに入れます。最優先事項は、現在成功しているテストが失敗し始めても最終的に無視されないようにすることで、この問題が山積せず、悪化し始めるのを防ぐことです。

ある意味ではあなたは幸運です。失敗してはいけないテスト（少なくとも何かが間違っているという警告を表示する）がある方が、合格してはいけない（セキュリティについて誤った感覚を与える）テストよりも優れています。
もちろん、前者がある場合は後者もある可能性が高いです（したがって、合格するが失敗するはずのテスト）。

既に述べたように、今のところ、これらの失敗したテストを無効にしますが、テストログにメッセージを表示して、それらについての一定のリマインダーを出力させます。
しかし、あなたは間違いなくテストスイート全体を調べるリソースを見つけて、合格するべきではないテストを除外します。それらはそれぞれ、あなたのコードで現在検出していないバグがコードにあることを意味するためですテストサイクル。

コードベースの上にぶら下がっている暗い雲を使用すると、テストを完全にレビューするための予算を得ることができるかもしれません。失敗すべきではありませんが、テストがコード内のエラーを適切に検出していることを信頼していないこと、テストセットがジョブを実行することを信頼していないことを信頼していないこと。
私が以前の会社でそれをやったとき、私はそのようなレビューのために働いていましたが、コードが何をすべきかについての間違った仮定で何百ものテストが書かれていることがわかりました（コードは同じ間違った仮定を使って書かれていました）本当にないはずです。これを修正することで、（大部分は重要ではありませんでしたが）いくつかの重要なシステムをダウンさせる可能性のある厄介なコーナーケースバグの多くを解決しました。

ユニットテストに失敗すると、ビルドが破損します。それを実現し、その目標を設定するためにあなたに良い。人間の心は、しつこい誤報の発生源よりも完全に何も無視できません。

これらのテストを捨てて、振り返らないでください。彼らが何年も失敗していて、今までに対処されていない場合、それらは優先事項ではありません。

部族の知識に関しては、部族の知識を持つ人々がまだ周りにいるなら、彼らは今までに失敗したテストを修正すべきだった。そうでない場合、再度、これらは優先順位ではありません。

部族の知識がない場合、あなたとあなたのチームはロジックの所有権を取得する必要があります。失敗したテストは役に立つよりも誤解を招く可能性があります-世界は前進したかもしれません。

関連する新しいテストを作成し、優れたコードの作成に取り掛かります。