失敗を登録し続けるべきでしょうか?

Question

私は、管理しているアプリの自動回帰テスト スイートに取り組んでいます。自動回帰テストの開発中に、ほぼ間違いなくバグであるいくつかの動作に遭遇しました。そこで、今のところ、失敗を記録しないように自動回帰テストを変更しました。つまり、この悪い動作を意図的に許可しているのです。

したがって、このサイトの他の人の意見に興味があります。明らかに、このエラー動作が確実に修正されるように、欠陥追跡にバグを追加します。しかし、常に失敗を示すように回帰テストを変更するか、欠陥のある動作を修正するまで回帰テストを壊れたままにして失敗しないようにする、（いずれにしても）説得力のある理由はあるのでしょうか?私はこれを他のタイプの質問の 6/16 だと考えていますが、他の人は違う見方をするかもしれないと思ったのでここで質問しました。

---

@ポール・トンブリン

念のため言っておきますが、私はテストを削除することを考えたことはありません。私は単に、テストを実行するたびに失敗を許容できるように、合格/不合格の条件を変更することを検討していました。

既知の原因による失敗の繰り返しが、最終的には C++ で警告のように扱われるのではないかと少し心配しています。C++ コード内に警告が表示されても、単なる無駄なノイズだと考えて無視する開発者を私は知っています。既知の失敗を回帰スイートに残すと、人々が他の、おそらくより重要な失敗を無視し始めるのではないかと心配しています。

ところで、誤解のないように言っておきますが、私は C++ の警告は強力なコードを作成する上で重要な助けになると考えていますが、これまでに会った他の C++ 開発者から判断すると、私は少数派だと思います。

Answer 1

私は「そうだね！」と言うでしょう。単純な事実は、それは失敗しているのかということです。はい！その後、ログに記録されるはずです。失敗したテストを通過させることにより、テストがかなり危険にさらされていることになります。

私が個人的に懸念していることの 1 つは、これを実行してバスの下に入った場合、「パッチ」が削除されない可能性があることです。つまり、「バグ修正」後でもバグが残る可能性があります。

そのままにして、プロジェクト ノートを更新し、おそらく (可能であれば) 重大度を下げることもありますが、壊れたものをチェックしているものを壊さないでください ;)

Answer 2

テストをやめたら、それがいつ修正されるか、そしてさらに重要なことに、再び壊れるかどうかをどうやって知ることができるのでしょうか?テストを再度追加するのを忘れる可能性が高いため、テストを削除することには反対です。

Answer 3

単体テストに「スヌーズ」機能を追加しました。これにより、基本的に「この日付から X 週間の失敗を無視する」という属性をテストに付けることができました。開発者は、しばらく修正されないとわかっているテストにこれで注釈を付けることができますが、将来的に手動で再度有効にするために介入する必要はなく、テストは指定された時間にテスト スイートに戻るだけです。

Answer 4

期待どおりの結果が得られない場合は、失敗のままにする必要があります。

そうでなければ、無視するのは簡単です。物事をシンプルにしてください。うまくいくかどうかはわかりません。失敗か成功か:)

-- ケビン・フェアチャイルド

Answer 5

私は Paul の発言の大部分に同意しますが、議論のもう一方の側面は、厳密に言えば、回帰テストは単なる古いバグではなく、プログラムの動作の変更をテストするものであるということです。特に、以前は機能していたものが壊れたときに通知することになっています。

これは結局、このアプリで他の種類のテストが実行されるかどうかに関係すると思います。何らかの単体テスト システムがある場合は、回帰テストではなく、このテストの方が (少なくともバグが修正されるまでは) 適切な場所になる可能性があります。ただし、回帰テストが唯一のテストである場合は、おそらくテストをそのままにしておくでしょう。

Answer 6

バグがある場合はテストを失敗させるのが最善ですが、これは多くの場合非現実的な選択です。ある領域に初めてテストを追加するときは、発見したバグに行き詰まり、主な目的を達成できなくなることが特によくあります。また、長時間失敗するテストは非常にノイズとなり、無視しやすくなります。

失敗するテストを作成することはバグ修正の一部であり、バグ修正が重要な場合にのみ本当に重要です。これは、現在の製品と品質の優先順位によって決定する必要があります。他の作業の副作用としてテストを作成する場合、それは良いことですが、実際の優先事項から気をそらしてはいけません。

テストを改善する際に発見されたバグを警告にし、バグを報告することをお勧めします。これは幅優先のアプローチであり、学んだことを実際に活用しながら、現在のタスクを完了することができます。バグの修正が予定されている場合、テストは簡単に実際に失敗する可能性があります。

他の回答者とは異なり、失敗は警告と同じくらい簡単に無視でき、失敗を無視できるようにチームを訓練するコストが高すぎるため、失敗が起こらないと私は思います。この作業の一環として失敗するテストを作成すると、タスクによって回帰テスト スイートが改善されていたときに、回帰テスト スイートのユーティリティが破壊されてしまうことになります。

Answer 7

テストに不合格になることは、ある種の悔しさです。壊れたコードと未完成のコードには違いがあり、テストに直ちに対処する必要があるかどうかは、この失敗したテストがどのような状況を明らかにするかによって決まります。

壊れている場合は、早めに修理する必要があります。未完了の場合は、時間のあるときに処理してください。

どちらの場合でも、（今のところ）悪い動作をしていても問題ないことは明らかなので、問題が記録されている限り、それを修正する時間ができるまで、それについてしつこく言わせないほうがよいでしょう。