本番環境でバグが見つかった場合、意図的にビルドを中断する必要がありますか？

エンドユーザーが本番環境で深刻なバグを見つけた場合、そのバグをカバーするために失敗した単体テストを追加し、バグが修正されるまで意図的にビルドを壊すことは理にかなっています。これに対する私の論理的根拠は、ビルドがずっと失敗していたはずだったが、自動化されたテストカバレッジが不十分だったためではなかったということです。

私の同僚の何人かは、失敗した単体テストはチェックインすべきではないという意見に異議を唱えています。通常のTDDプラクティスの観点からはこの観点に同意しますが、生産バグは異なる方法で処理する必要があると思います。既知の欠陥で成功するビルド？

他の誰かがこのシナリオを処理するための実証済みの戦略を持っていますか？意図的にビルドを壊すことは他のチームメンバーを混乱させる可能性があることを理解していますが、それはブランチの使用方法に完全に依存します。

私たちの戦略は次のとおりです。

失敗したテストをチェックインし@Ignore("fails because of Bug #1234")ますが、注釈を付けます。

そうすれば、テストはそこにありますが、ビルドは壊れません。

もちろん、バグdbで無視されたテストに注意するため@Ignore、テストが修正されると削除されます。これは、バグ修正の簡単なチェックとしても機能します。

失敗したテストでビルドを中断するポイントは、何らかの形でチームにプレッシャーをかけることではなく、問題を警告することです。問題が特定され、バグDBに登録されると、ビルドごとにテストを実行しても意味がありません。失敗することはわかっています。

もちろん、バグはまだ修正されているはずです。しかし、修正をスケジュールすることはビジネス上の決定であり、したがって開発者の関心事ではありません... 。

なぜビルドが既知の欠陥で成功するのを許可したいのですか？

時々、時間的な制約があるからです。または、バグが非常に小さいため、単体テストと修正に必要な数日間、製品の出荷を遅らせる価値はありません。

また、バグを見つけるたびに意図的にビルドを壊すことのポイントは何ですか？見つかった場合は、チーム全体に影響を与えずに修正します（または修正する担当者に割り当てます）。バグの修正を忘れないようにするには、バグ追跡システムで非常に重要としてマークする必要があります。

テストを行って、問題を（再）導入しないことを確認します。失敗したテストのリストは、バグ追跡システムに代わるものではありません。POVには、テストの失敗がバグを示すだけでなく、開発プロセスの失敗を示す（不注意から依存関係の特定の誤りまで）という妥当性があります。

「ビルドを中断する」とは、ビルドが正常に完了しないようにすることを意味します。失敗したテストはそれを行いません。これは、ビルドに既知の欠陥があることを示していますが、これは正確です。

ほとんどのビルドサーバーは、テストのステータスを経時的に追跡し、追加されてから失敗したテストと回帰（異なるテストに合格し、以前は成功していなかった）に異なる分類を割り当て、また、回帰が起こった。

失敗したテストを追加する必要があると主張しますが、明示的に「失敗したテスト」としてではありません。

@BenVoigtが答えで指摘しているように、テストの失敗は必ずしも「ビルドを壊す」とは限りません。用語はチームごとに異なる可能性があると思いますが、コードはコンパイルされたままで、製品はテストに失敗しても出荷できます。

この状況で自問すべきことは、

テストの目的は何ですか？

誰もがコードについて気分を良くするためだけにテストが存在する場合、コードについて誰もが気分を悪くするためだけに失敗したテストを追加しても、生産的ではないようです。しかし、そもそもテストの生産性はどの程度ですか？

私の主張は、テストはビジネス要件の反映であるべきだということです。だから、「バグ」は要件が適切に満たされていないことを示しているが発見された場合、あるもテストが適切または完全にビジネス要件を反映していないことを示し。

それが最初に修正されるバグです。「失敗したテストを追加する」のではありません。あなたはしている修正テストがビジネス要件をより正確に反映します。コードがそれらのテストに合格しない場合、それは良いことです。それはテストが仕事をしていることを意味します。

コードを修正する優先順位は、ビジネスによって決定されます。しかし、テストが修正されるまで、その優先順位を本当に決定できますか？ビジネスは、何が失敗しているか、どのように失敗しているか、そしてなぜ失敗しているのかを正確に把握して、優先順位を決定する必要があります。テストはこれを示す必要があります。

完全にパスしないテストを持つことは悪いことではありません。既知の問題の重要なアーティファクトを作成し、それに応じて優先順位を付けて処理します。完全にはないテスト持つテストを、しかし、問題となっています。テスト自体の価値に疑問を投げかけます。

別の言い方をすれば... ビルドは既に壊れています。あなたが決めているのは、その事実に注意を喚起するかどうかです。

テスト自動化チームでは、テストの欠陥ではなく製品の欠陥が原因で失敗する限り、失敗したテストをチェックインします。そうすれば、開発チームがそれを壊したという証拠が得られます。ビルドを壊すことは非常に嫌われますが、それは完全にコンパイル可能であるが失敗するテストをチェックインすることと同じではありません。

バグが修正されるまで失敗することがわかっているテストを作成するのは良い考えです。それがTDDの基礎です。

ビルドを壊すのは悪い考えです。どうして？なぜなら、それが修正されるまで何も進むことができないからです。基本的に、開発の他のすべての側面をブロックします。

例1
アプリケーションが大きく、コンポーネントが多数ある場合はどうなりますか？それらのコンポーネントが、独自のリリースサイクルで他のチームによって作業されている場合はどうなりますか？タフ！彼らはあなたのバグ修正を待つ必要があります！

例2
最初のバグを修正するのが難しく、優先順位の高い別のバグを見つけた場合はどうなりますか？2番目のバグのビルドも中断しますか？これで、両方が修正されるまでビルドできません。人為的な依存関係を作成しました。

テストに失敗するとビルドが停止する論理的な理由はありません。これは、開発チームが、既知のバグを含むビルドをリリースすることの長所と短所を比較検討する必要がある決定です（おそらく、経営陣との議論で）。これはソフトウェア開発では非常に一般的であり、ほとんどすべての主要なソフトウェアは少なくともいくつかの既知の問題とともにリリースされます。

テストが果たすべき役割と、採用されたビルドシステム/プロセスに結果がどのように影響するかによって異なります。ビルドを壊すことについての私の理解はベンのものと同じであり、同時に、既存のテストを壊すコードを意図的にチェックインするべきではありません。これらのテストが「後で」行われた場合、他の人への不必要な混乱を減らすためにそれらを無視することは「大丈夫」かもしれませんが、失敗したテストを無視するこのプラクティスを見つけます（テストが合格するように見える）単体テストの場合）、そのようなテストを赤でも緑でもないことを示す方法がない限り。

もちろんバグに依存しますが、一般に、手動または自動テストで特定されなかった何かがうまくいかなかった場合、それはカバレッジにギャップがあることを意味します。私は間違いなく根本原因を突き止め、問題の上に単体テストケースを平手打ちすることをお勧めします。

メンテナンスブランチからのホットフィックスが計画されている本番の問題である場合、修正がメインラインで機能し、開発者が熱心なマージ競合解決で誤って修正を吹き飛ばすことができないことも確認する必要があります。 。

さらに、リリースポリシーに応じて、新しく更新された単体テストの存在は、開発者が単に問題を変更するのではなく、実際に問題を修正したことを確認するのに役立ちます[（問題またはテスト？）]新しい単体テストの要件を修正します。

ビルドに失敗することがわかっているテストを追加する際の問題の1つは、ビルドが失敗することを期待しているため、チームが失敗したテストを無視する傾向があることです。ビルドシステムに依存しますが、テストの失敗が常に「何かが壊れた」ことを意味しない場合、テストの失敗に注意を払うのは簡単です。

あなたのチームがその考え方に入るのを助けたくありません。

そのため、テストを追加する必要があるが、バグが修正されるまで、自動ビルドの目的のために「無視」としてマークすることに同意します。

何らかの方法でバグをテストとして「チェックイン」する必要があると思いますが、修正したときに再び発生せず、何らかの方法でそれを優先するので、ビルド（/テスト）を壊さないことが最善だと思います。その理由は、その後ビルドを破壊するコミットが、破壊されたテストの背後に隠されるからです。したがって、このバグの壊れたテストをチェックインすることにより、チーム全体がこのバグを修正するために作業を脇に置くことを要求します。それが起こらない場合、そのように追跡可能でないコミットを壊すことになってしまうかもしれません。

したがって、保留中のテストとしてコミットし、保留中のテストを持たないようにチームで優先することをお勧めします。

別のオプションは、失敗したテストをソース管理システムの別のブランチにチェックインすることです。あなたの慣習に応じて、これは実行可能かどうかが異なります。些細ではないバグの修正など、進行中の作業のために新しいブランチを開くことがあります。