6

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

なので、このサイトの他の人の意見に興味があります。明らかに、このエラー動作が修正されることを確認するために、バグ追跡にバグを追加します。しかし、回帰テストを変更して常に失敗を示すようにするか、回帰テストを中断したままにして、欠陥のある動作を修正できるようになるまで失敗しないようにする説得力のある理由はありますか?私はこれを他のタイプの質問の6分の1と考えていますが、他の人がそれを異なって見るかもしれないと思ったので、ここで尋ねます。


@ポール・トゥームリン、

明確にするために、私はテストを削除することを考えたことがありません。テストを実行するたびに失敗が発生することなく、失敗を許容するように合格/不合格条件を変更することを検討していました。

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

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

4

7 に答える 7

5

テストをやめた場合、それがいつ修正されたかをどのように知ることができますか?さらに重要なことに、それが再び壊れたかどうかをどのように知ることができますか?もう一度テストを追加するのを忘れる可能性があるので、私はテストを行うことに反対です。

于 2008-09-03T12:51:07.563 に答える
4

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

于 2008-09-03T12:56:33.790 に答える
1

私は「ええ、地獄!」と言うでしょう。単純な事実は、それは失敗しているのでしょうか?はい!次に、ログに記録する必要があります。失敗したテストに合格させることで、テストをかなり妥協しています。

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

それを残し、プロジェクトのメモを更新し、おそらく(可能であれば)重大度を下げますが、壊れたものをチェックしているものを壊してはいけません;)

于 2008-09-03T12:52:21.710 に答える
1

期待どおりに動作しない場合は、失敗したままになるはずです。

そうでなければ、無視するのは簡単すぎます。物事をシンプルに保つ-それは機能するかしないか。失敗または成功:)

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

于 2008-09-03T12:52:30.760 に答える
1

Paulが言ったことのほとんどに同意しますが、議論の反対側は、厳密に言えば、回帰テストは、古いバグだけでなく、プログラムの動作の変化をテストすることになっているということです。彼らはあなたが以前は働いていた何かを壊したときにあなたに特に伝えることになっています。

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

于 2008-09-03T12:55:58.863 に答える
1

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

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

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

他の回答者とは異なり、失敗は警告と同じくらい簡単に無視できると思います。また、失敗を無視するようにチームをトレーニングするコストは、失敗を許容するには高すぎると思います。この取り組みの一環として失敗するテストを作成すると、タスクによって改善されていた回帰テスト スイートのユーティリティが失われてしまいます。

于 2012-10-30T15:51:27.457 に答える
0

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

壊れている場合は、後でではなく早く修正する必要があります。未完成の場合は、時間があるときに対処してください。

どちらの場合でも、問題がログに記録されている限り、問題を修正する時間があるまで問題が発生しない可能性があります。

于 2008-09-03T12:55:12.093 に答える