automated-tests - 開発中に失敗することが予想される単体/回帰テストをどのように処理しますか?

Question

ソフトウェア開発中に、コードベースに既知の問題であるバグが存在する場合があります。テストが適切に作成されている場合、これらのバグにより、回帰/単体テストが失敗します。

私たちのチームでは、失敗したテストをどのように管理すべきかについて、常に議論があります。

REVISIT または TODO コメントを使用して、失敗したテストケースをコメントアウトします。
- 利点:新しい欠陥が導入されたときは常にわかりますが、既に認識している欠陥ではありません。
- 欠点: コメントアウトされたテストケースを再確認するのを忘れる可能性があります。つまり、欠陥が見過ごされる可能性があります。
テストケースは失敗したままにします。
- 利点: スクリプトが失敗すると、欠陥が存在することが常に思い出されるため、欠陥の修正を忘れることはありません。
- 短所:障害ノイズにより、新しい欠陥が導入されたときに検出が困難です。

この点に関して、ベストプラクティスとは何かを探りたいと思います。個人的には、スクリプトが通過しているかどうかを判断するには、トライステートソリューションが最適だと思います。たとえば、スクリプトを実行すると、次のように表示されます。

合格率: 75%
失敗率 (予想): 20%
失敗率 (予期しない): 5%

基本的に、何らかのメタデータを使用して、(何らかの欠陥により) 失敗すると予想されるテストケースをマークします。これにより、テストの最後に引き続き失敗の結果が表示されますが、予期していなかった新しい失敗があるかどうかがすぐにわかります。これは、上記の 2 つの提案の最良の部分を採用しているように見えます。

これを管理するためのベストプラクティスはありますか?

score 6 · Accepted Answer

すぐにバグを修正します。

複雑すぎてすぐに実行できない場合は、単体テストするにはサイズが大きすぎる可能性があります。

単体テストを失い、欠陥をバグデータベースに入れます。そうすれば、可視性があり、優先順位を付けることができます。

score 6 · Accepted Answer

テストケースはそのままにしておきます。私の経験では、コードを次のようにコメントアウトします

// TODO:  fix test case

することに似ています：

// HAHA: you'll never revisit me

真面目な話、出荷が近づくにつれて、コードの TODO を再訪したいという欲求は薄れる傾向があります。特に、コードの他の部分の修正に集中しているため、単体テストのようなものについてはそうです。

おそらく「トライステート」ソリューションでテストを残してください。ただし、これらのケースをできるだけ早く修正することを強くお勧めします。定期的なリマインダーに関する私の問題は、人々がそれらを見た後、それらを大ざっぱに言い、「そうそう、私たちは常にこれらのエラーを取得しています...」と言う傾向があることです.

適切な例 -- 一部のコードでは、「スキップ可能なアサート」のアイデアを導入しました -- アサートは、問題があることを知らせるために存在しますが、テスターがそれらを通り過ぎて残りの部分に移動できるようにします。コード。QAが「そうそう、いつもその主張を受け取り、スキップ可能であると言われました」などと言い始め、バグが報告されていないことがわかりました。

私が提案しているのは、別の代替手段があるということだと思います。それは、テストケースで見つけたバグをすぐに修正することです。そうしない現実的な理由があるかもしれませんが、今その習慣を身につけることは、長期的にはより有益になる可能性があります.

score 2 · Accepted Answer

私は通常、Perl で作業しており、Perl の Test::* モジュールを使用すると、TODO ブロックを挿入できます。

TODO: {
  local $TODO = "This has not been implemented yet."

  # Tests expected to fail go here
}

テスト実行の詳細な出力では、$TODO 内のメッセージが、TODO ブロック内の各テストの成功/失敗レポートに追加され、失敗すると予想された理由が説明されます。テスト結果の概要では、すべての TODO テストが成功したものとして扱われますが、実際に成功した結果が返された場合は、それらも集計され、予期せず成功したテストの数が報告されます。

したがって、同様の機能を持つテストツールを見つけることをお勧めします。(または、テスト対象のコードが別の言語であっても、Perl をテストに使用してください...)

score 1 · Accepted Answer

私はこれらをIgnore属性 (これはNUnitを使用しています)を付けたままにしておく傾向があります。テストはテスト実行の出力に記載されているため、表示されているため、忘れないことを願っています。「無視」メッセージに問題/チケット ID を追加することを検討してください。そうすれば、根本的な問題が熟していると考えられるときに解決されます - 失敗したテストをすぐに修正するのは良いことですが、小さなバグは時が来るまで待たなければならないことがあります.

再コンパイルせずに実行できるという利点があるExplicit属性を検討しましたが、「理由」引数を取らず、実行する NUnit のバージョンではテストが表示されません。 unrun として出力されます。

score 1 · Accepted Answer

次のことを行いました。テストに階層を配置します。

例: 3 つのことをテストする必要があります。

ログインをテストします (ログイン、ユーザー名の取得、「最終ログイン日」またはおなじみのものの取得など)。
データベースの取得をテストします (特定の「schnitzelmitkartoffelsalat」を検索 - タグ、最新のタグを検索)
Web サービスのテスト (接続、バージョン番号の取得、簡易データの取得、詳細データの取得、データの変更)

括弧内に示されているように、すべてのテストポイントにはサブポイントがあります。これらを階層的に分割します。最後の例を見てみましょう:

3. Connect to a web service
    ...
3.1. Get the version number
    ...
3.2. Data:
    3.2.1. Get the version number
    3.2.2. Retrieve simple data
    3.2.3. Retrieve detailed data
    3.2.4. Change data

ポイントが (開発中に) 失敗した場合は、正確なエラーメッセージを 1 つ挙げてください。すなわち 3.2.2. 失敗した。その場合、テストユニットは 3.2.3 のテストを実行しません。および 3.2.4。. このようにして、「3.2.2 に失敗しました」という 1 つの (正確な) エラーメッセージが表示されます。したがって、その問題を (最初に) 解決することはプログラマーに任せ、3.2.3 を処理しません。および 3.2.4。これではうまくいかないからです。

これは、問題を明確にし、最初に何をしなければならないかを明確にするのに大いに役立ちました.

score 0 · Accepted Answer

Joel の"12 Steps to Better Code"の #5 では、新しいコードを書く前にバグを修正しています。

コードにバグがあり、それを最初に実行しようとしたときに見つけた場合、すべてのコードがまだ記憶に新しいため、すぐに修正することができます。

数日前に書いたコードにバグが見つかった場合、それを突き止めるのにしばらく時間がかかりますが、書いたコードを読み直すと、すべてを覚えていて、修正することができます。妥当な時間内にバグ。

しかし、数か月前に書いたコードにバグが見つかった場合、そのコードについて多くのことを忘れている可能性があり、修正するのははるかに困難です。その時までに、他の誰かのコードを修正している可能性があり、彼らは休暇で Aruba にいる可能性があります。その場合、バグを修正することは科学のようなものです。ゆっくりと、整然と、細心の注意を払う必要があります。治療法を発見するには長い時間がかかります。

また、出荷済みのコードにバグが見つかった場合、その修正に莫大な費用がかかります。

ただし、失敗したテストを本当に無視したい場合は、使用するテストフレームワークで [Ignore] 属性または同等の属性を使用してください。MbUnit の HTML 出力では、無視されたテストは黄色で表示され、失敗したテストは赤色で表示されます。これにより、新しく失敗したテストに簡単に気付くことができますが、既知の失敗したテストを見失うことはありません。

score 0 · Accepted Answer

コードベースから「TODO」コメントを生成する TODO ウォッチャーが必要だと思います。TODOはテストメタデータです。これは、既知のエラーメッセージの 1 行前にあり、関連付けが非常に簡単です。

TODOは良いです。それらを使用します。それらを実際に定期的にバックログに入れることで、それらを積極的に管理します。

automated-tests - 開発中に失敗することが予想される単体/回帰テストをどのように処理しますか?

7 に答える 7

Related

Reference