テストの修正が優先事項と見なされる環境を作成するにはどうすればよいですか？

私は中規模企業のソフトウェアエンジニアです。TeamCityで実行されるかなり堅牢なテストプラットフォームがあります。すべてのチェックインで単体テストを実行し、毎日の単体テスト/ BVTを実行します。

問題は、大量の単体テストが失敗していることです。

ユニットテストが絶えず壊れていて、メンテナンスされていない場合、かなり頻繁にユニットテストの無意味さを引き出します。変更によってリグレッションが発生したかどうかを確認できないと、単体テストプラットフォームの価値のほとんどが失われます。

良い習慣の文化を作り出す種を植えたいです。壊れたときにテストを修正し、それらを価値あるものとみなし、他の作業とともにテストの修正を優先します。

私は賄ber（焼き菓子！）を試みましたが、単純に尋ねて、チームリーダーに話しました。誰もがそれは良いアイデアだと言いますが、私はそれについて何かをしている唯一の人であると思います。

他の人にテストの修正を奨励し、スプリント内でのテスト修正の優先順位付けを開始する最良の方法は何ですか？

これを尋ねる主観的な方法がなければ、どんなヒントでも喜んで受け入れます。

テストを修正せずに実際に何かをリリースできないようにします。

1. テストが失敗した場合、ビルドに失敗します。
2. テストが無視された場合、ビルドは失敗します。
3. テストカバレッジが特定のレベルを下回った場合、ビルドに失敗します（そのため、テストを削除して回避することはできません）。
4. CIサーバーを使用してリリースビルドを行い、サーバーのビルドドロップからのビルドのみがUAT /ステージング/プロダクション/その他に昇格できるようにします。

問題は、ビルドが一度に約15分以上壊れている場合（テストの失敗も含む）、継続的な統合を行っていないことです。

「核オプション」は、ソース管理サーバーに、ビルドを中断したユーザー以外のユーザーからのコミット/チェックインを拒否させることです。明らかに、管理者は、その人が休暇をとる場合、一時的にこれをオーバーライドできる必要がありますが、テストを修正するまでチーム全員がねじ込まれていることを誰もが知っている場合、すぐに解決します。

適切なポリシー（自動化されている場合はさらに良い）は、ビルドが15分間失敗した後、ソースを最後の既知の安定したコミットに戻すことです。言い換えれば、それを修正できない場合、またはビルドまたはテストが壊れる原因がわからない場合は、それを元に戻し、解決されるまでローカルで作業します -他の開発者が親指をいじる間は絶対にいじらないでください彼らが気にしない問題。

PS 既に多くのテストが失敗している場合、CIで「最後のしきい値」を使用できます。前回よりもテストの失敗が多い場合にのみビルドが失敗するように設定します。これは、カバレッジルールとともに、開発者が作業を継続できるようにする場合、最終的にテスト状況を改善することを強制します。

PPSこれは一部の人にとって厳しいと思われるかもしれませんが、それはすべてあなたの文化にかかっています。あなたは、人々がちょうどポイントを取得した場合はありません（私は時々それらを思い出させるために持っているが、私のチームが行うことはほとんどない）失敗ビルド壊れたかのテストを残して、あなたはルールの厳しいセットを続行する必要はありません。IMOですが、破損した単体テストでは常にビルドに失敗します。統合/ブラウザテストが失敗することがあります。

失敗する単体テストは問題ではありません。それらは症状です。

本当の問題は文化にあります。優しく踏む必要があります。ここではドラゴンです。自分で文化を変えることはできず、きしむ音を立てることは、結局、あなたを追放されます。文字通り。

あなたが原因を擁護し、道を先導する高齢者を見つけようとするなら、私は提案する。それが失敗した場合は、一般的な開発者会議で指をさしたり、名前を呼ぶことなく、それを上げてみてください。別の方法は、適切な仕事をする責任を自分で負うことです。チェックインするたびに、さらにいくつかのテストを修正するだけです。時間の経過とともに失敗するテストの数を示すチャートを壁に保管してください。他の人はそれを見るでしょう：多分彼らはオプトインするでしょう。

簡単な答えはありません。