継続的統合環境でユニットテストを行うタイミング
私たちは、CIの手法と方法論を組織に取り入れようとしています。私は現在、Jez HumbleとDavid Farleyによって書かれた "Continuous Delivery"の本のいくつかのポイントを読んでいます。そして私が議論している点は、ユニットテストをいつ実行すべきかです-git commitの前または後で。この本は、コミットテストスイートの一部として、チェックイン後にユニットテストを実行することを推奨しているようです。しかし、チェックインする前に単体テストを実施する方が理にかなっているのではないでしょうか。
コメントをいただければ幸いです。
通常、開発者はチェックイン前にそれらを手動で実行し、CIサーバーはチェックイン後に自動的に実行します。プログラマーは通常、取り組んでいる構成で増分ビルドの単体テストを実行することについてかなり優れていますが、何もしませんバージョン管理からの完全にクリーンなチェックアウトからクリーンビルドを行う、製品のすべての構成のテストを実行する、それらに依存するダウンストリームプロジェクトのすべてのユニットテストを実行するなど。
これが、CIサーバーがコミット後にテストを「再実行」する理由です。すべてのテストを確実に実行したブランチが必要な場合は、マスターブランチに実際にマージされる前にテストを実行するように設定できます。
CIサーバーで自動テストを実行することは、実際には統合テストの一種です。
開発者がローカルでテストを実行するとき、行った変更がシステム全体の状態と一致しているかどうかを検証していますコードをチェックアウトしたとき。
一方、CIサーバーは、すべての開発者の作業を継続的に統合しています。 itが自動テストを実行する場合、開発者がメッシュtogetherを正しく変更したことを検証します。
壊れたテスト/壊れたコードをローカルリポジトリにコミットすること自体には問題はありません。中央リポジトリへのプッシュを見越して、特別に指定された統合ブランチにローカルでコミットすると、問題が発生し始めます。壊れたものを中央リポジトリの特別に指定されたブランチにプッシュすると、実際の問題が発生します。
壊れたテストのコミットを完全に排除するシステムは壊れたシステムです。コードを書く前にテストを書くというマントラに従うと、テストは最初は必ず失敗します。意図的に壊れたテストをコミットすることを不可能にすることは意味がありません。
壊れたコードのコミットを完全に排除するシステムも壊れたシステムです。開発者は、コンパイルすらできない疑似コードから始めて、機能しない実際のコードに進み、最後に明らかに機能する実際のコードに進むことができます。これらの最初のアイデアをコミットすることを不可能にすることは意味がありません。壊れたコードをローカルリポジトリにコミットすることで、後工程を2回以上節約できました。
「Zen of Python」から言葉を盗み、「構成管理は面白そうな素晴らしいアイデアの1つです。もっと多くのことをしましょう！」
私は、完全なローカルテストが不可能な難解な環境で作業する傾向があります（スーパーコンピューター、強力な非スーパーコンピューターのネットワーク、組み込みデバイス、組み込みデバイスのネットワークなど、机の上にはありません）。これにより、CMシステムで過度にアグレッシブなフックを少し過度に恐れることになります。
このような難解な環境で作業していない場合でも、すべてのコミットのテストを自動的にトリガーする（そして、失敗した場合はコミットを拒否する）コミットフックを使用することは、悪い考えです。頻繁にコミットし、頻繁にマージすることを人々に奨励するのが最善です。コミットされていないコードを含むブランチをマージすることは、かなりの量の構成管理の不安のレシピです。頻繁にマージしないと、さらに多くの構成管理の不安が生じます。
逆に、フックをまったく持たず、開発者がビルドを壊したときに恥ずかしいことをするようにすることも、悪い考えです。必要なのは、人々を最も効率的にする力を与え、しかも非常に賢い人々でさえもできない愚かなことをする人々から保護する妥協です。