「合格/破損ビルド」インジケータの代替手段
コミットごとにテストを実行する継続的な統合を行う場合、一般的なベストプラクティスは、すべてのテストを常にパスすることです（「ビルドを中断しないでください」）。 私はそれに関するいくつかの問題を見つけます： たとえば、チケットに対応するテストを作成して、オープンソースプロジェクトを支援することはできません。失敗したテストを含むオープンソースプロジェクトにプルリクエストを提案した場合、ビルドは失敗としてマークされ、プロジェクトは「ビルドを壊す」ためリポジトリにマージされたくないでしょう。 そして、レポでテストに失敗するのは悪いことではないと思います。それは、トラッカーに未解決の問題があるようなものです。これらは修正されるのを待っているものです。 同じことが会社にも言えます。TDDを使用している場合、テストを作成し、コミットしてから、テストを満たすロジックコードを作成することはできません。つまり、ラップトップで4〜5個のテストを書いた場合、休日に行く前にテストをコミットすることはできません。誰も私の仕事を取り戻すことはできません。たとえばメールで送信する場合を除き、同僚と「共有」することさえできません。また、テストの作成者とモデルの作成者との作業も妨げられます。 言うまでもなく、私はビルドプロセスを誤用/誤解しているか、継続的な統合を行っていますか？「通過する」/「通過しない」という指標は狭すぎるように思えます。 継続的な統合とTDD互換性を実現する方法はありますか？ 「新しいテスト」（失敗する可能性がある）と「回帰テスト」（以前は機能していたため失敗するべきではない）を区別するための標準的なソリューション/プラクティスがあるかもしれません。