本番環境でバグが見つかった場合、意図的にビルドを中断する必要がありますか？
エンドユーザーが本番環境で重大なバグを発見した場合、失敗するユニットテストを追加してそのバグをカバーし、バグが修正されるまで意図的にビルドを中断することは私には理にかなっています。これの私の理論的根拠は、ビルドずっと失敗していたはずですですが、自動化されたテストカバレッジが不十分だったためではありませんでした。
私の同僚の何人かは、失敗した単体テストはチェックインされるべきではないと言って反対しました。私は通常のTDDプラクティスに関してこの見解に同意しますが、本番環境のバグは異なる方法で処理されるべきだと思います-結局、なぜ許可したいのですか？既知の欠陥で成功するビルド？
他の誰かがこのシナリオを処理するための実証済みの戦略を持っていますか？ビルドを意図的に破壊すると他のチームメンバーに混乱をもたらす可能性があることを理解していますが、それは完全にブランチの使用方法に依存します。
私たちの戦略は：
失敗したテストをチェックインしますが、@Ignore("fails because of Bug #1234")で注釈を付けます。
そうすれば、テストはそこにありますが、ビルドは壊れません。
もちろん、バグdbで無視されたテストに注意するので、@Ignoreテストが修正されると削除されます。これは、バグ修正の簡単なチェックとしても機能します。
失敗したテストでビルドを中断する目的は、どういうわけかチームにプレッシャーをかけることではなく、問題について彼らに警告することです。問題が特定されてバグDBにファイルされたら、ビルドごとにテストを実行しても意味がありません-失敗することがわかります。
もちろん、バグはまだ修正されているはずです。しかし、修正のスケジュールはビジネス上の決定であり、開発者の懸念ではありません...私にとって、バグがバグDBに登録されると、顧客/製品の所有者が修正を要求するまで、それは私の問題ではなくなります。 。
ビルドを既知の欠陥で成功させる理由は何ですか？
時々、あなたには時間の制約があるからです。または、バグが非常に小さいため、単体テストと修正に必要な数日間、製品の出荷を遅らせるだけの価値はありません。
また、バグを見つけるたびに意図的にビルドを中断することのポイントは何ですか？見つかった場合は、チーム全体に影響を与えずに、修正（または修正担当者に割り当て）します。バグを修正することを覚えておきたい場合は、バグ追跡システムで非常に重要なものとしてマークする必要があります。
テストは、問題が（再）導入されないようにするためにあります。失敗したテストのリストは、バグ追跡システムの代わりにはなりません。テストの失敗はバグを示すだけでなく、開発プロセスの失敗（不注意から不適切に特定された依存関係まで）の兆候でもあるというPOVにはいくつかの有効性があります。
「ビルドを壊す」とはビルドが正常に完了しないようにするためを意味します。失敗したテストはそれを行いません。これは、ビルドに既知の欠陥があることを示しています。これは正確です。
ほとんどのビルドサーバーはテストのステータスを時間の経過とともに追跡し、追加されたために失敗していたテストに別の分類を割り当てます。退行が起こりました。
失敗したテストを追加する必要があると私は主張しますが、「失敗したテスト」として明示的にではありません。
@BenVoigtが 彼の回答 で指摘しているように、失敗したテストは必ずしも「ビルドを中断」するわけではありません。用語はチームごとに異なる可能性がありますが、コードは引き続きコンパイルされ、製品はテストに失敗して出荷できます。
この状況で自問すべきことは、
達成することを意図したテストは何ですか？
テストがすべての人がコードについて気分を良くするためだけにある場合、失敗したテストを追加して全員がコードについて気分が悪くなるようにしても、生産的ではないように見えます。しかし、そもそもテストの生産性はどのくらいですか？
私の主張はテストはビジネス要件の反映であるべきだということです。したがって、要件が適切に満たされていないことを示す「バグ」が見つかった場合、それはまたテストがビジネス要件を適切または完全に反映していないことを示しています。
それが最初に修正されるバグです。 「失敗したテストを追加する」のではありません。あなたはビジネス要件をより正確に反映するようにテストを修正しています。コードがこれらのテストに合格しない場合、それは良いことです。それはテストが彼らの仕事をしていることを意味します。
コードを修正する優先順位は、ビジネスによって決定されます。しかし、テストが修正されるまで、その優先順位を本当に決定できるでしょうか？ビジネスは、優先順位を決定するために、何が失敗しているのか、どのように失敗しているのか、なぜ失敗しているのかを正確に把握している必要があります。テストはこれを示す必要があります。
完全に合格しないテストがあることは悪いことではありません。それは、優先順位が付けられ、それに応じて処理される既知の問題の優れた成果物を作成します。ただし、完全にtestではないテストがあることは問題です。テスト自体の価値に疑問を投げかけます。
別の言い方をすると...ビルドは既に壊れています。あなたが決定しているのは、その事実に注意を喚起するかどうかです。
テスト自動化チームでは、テストの欠陥ではなく、製品の欠陥が原因で失敗したテストをチェックインします。このようにして、開発チームがそれを破ったという証拠を持っています。ビルドを壊すことは非常に嫌われますが、それは完全にコンパイル可能ですが失敗したテストをチェックインすることと同じではありません。
バグが修正されるまで失敗することがわかっているテストを作成するのは良い考えです。それがTDDの基礎です。
ビルドを壊すことは悪い考えです。どうして？それは修正されるまで何も進むことができないことを意味するからです。それは本質的に開発の他のすべての側面をブロックします。
例1
アプリケーションが大きく変動し、多くのコンポーネントがある場合はどうなりますか？それらのコンポーネントが独自のリリースサイクルを持つ他のチームによって作業されている場合はどうなりますか？タフ！彼らはあなたのバグ修正を待つ必要があります！
例2
最初のバグの修正が困難で、優先度の高い別のバグを見つけた場合はどうなりますか？ 2番目のバグのビルドも中断しますか？ bothが修正されるまでビルドできません。人工的な依存関係を作成しました。
テストに失敗するとビルドが停止する論理的な理由はありません。これは、既知のバグを含むビルドをリリースすることの長所と短所を、開発チームが（おそらく管理の議論で）決定する必要がある決定です。これはソフトウェア開発では非常に一般的です。ほとんどすべての主要なソフトウェアがリリースされており、少なくともsome既知の問題があります。
もちろん、それはバグに依存しますが、一般的に、手動または自動テストで特定されなかった問題が発生した場合、カバレッジにギャップがあることを意味します。私は間違いなく根本的な原因を解明し、問題の上にユニットテストケースを適用することをお勧めします。
メンテナンスブランチからのホットフィックスが計画されているのが本番の問題である場合は、フィックスがメインラインで機能すること、および開発者が熱心すぎるマージ競合解決で誤ってフィックスを吹き飛ばすことがないことを確認する必要もあります。 。
さらに、リリースポリシーによっては、新しく更新された単体テストの存在により、単に変更するのではなく、開発者が実際に問題を修正したことを確認できます[（問題またはテスト？）]。新しい単体テストの正しい要件。
これは、テストが果たすべき役割と、その結果が採用されたビルドシステム/プロセスにどのように影響するかによって異なります。ビルドを壊すことについての私の理解はベンの理解と同じであり、同時に既存のテストを壊すコードを故意にチェックインすべきではありません。これらのテストが「後で」行われた場合、他のユーザーに不必要な混乱を生じさせないためにそれらを無視することは「大丈夫」かもしれませんが、失敗したテストを無視する（それらが合格するように見える）ため、むしろ（特にそうです）単体テストの場合）、そのようなテストを赤でも緑でもないことを示す方法がない限り。
失敗することがわかっているテストをビルドに追加する際の問題の1つは、ビルドが失敗することを期待しているため、失敗したテストを無視する癖がチームにある可能性があることです。ビルドシステムに依存しますが、失敗したテストが常に「何かが壊れた」という意味ではない場合、失敗したテストにあまり注意を払うのは簡単です。
チームがそのような考え方に入るのを手助けしたくありません。
したがって、バグが修正されるまで、自動ビルドの目的で テストを追加しますが、「無視」とマークします にする必要があるというsleskeに同意します。
バグをテストとして何らかの方法で「チェックイン」する必要があると思いますが、それを修正するときに再度発生しないようにし、何らかの方法で優先順位を付ける場合は、ビルド（/テスト）を壊さないことが最善だと思います。その理由は、その後ビルドを壊すコミットがあなたの壊れたテストの後ろに隠されるからです。したがって、このバグの壊れたテストをチェックインすることにより、チーム全体がこのバグを修正するために作業をわきに置くことを要求します。それが起こらない場合は、そのようなものとして追跡できないコミットを壊してしまうかもしれません。
したがって、保留中のテストとしてコミットし、保留中のテストがないことをチームの優先事項にすることをお勧めします。
別のオプションは、失敗したテストをソース管理システムの別のブランチにチェックインすることです。あなたの慣行に応じて、これは可能かそうでないかです。些細なことではないバグの修正など、進行中の作業のために新しいブランチを開くことがあります。