統合テストを継続的統合（CI）に含める必要がありますか？

Webアプリケーションを開発しており、Hudsonがコンパイル、単体テスト、静的コード分析などの典型的な仕事をしていると仮定します。

ただし、注意が必要なのは、Hudson がアプリケーションサーバーを展開して起動し、統合ジョブを実行してから、以前のジョブが完了したことです。

これは、データベース接続、3番目の部分のアプリケーション接続、ソケットポートのリスニング、環境変数、サーバーの起動失敗の処理など、いくつかの困難なことを意味します。さらに悪いことに、統合テストは統合テストを簡単に破ることができます。

統合テストを継続統合（CI）に含める必要があると思いますか？手動でできますか？または統合テストを簡素化しますか？

継続的インテグレーションという名前は多くを語っています。すでに統合している場所よりも統合テストを行うのに適した場所はどこですか？
もちろん、これらのテストが行​​われる唯一の場所ではありません。開発時には、変更が単独で機能することだけでなく、結局は物事を壊さないようにする必要があります。
最終的には、テストが制限されている人やステージを非難して厳格に定義しようとすることは、非生産的であることは、すべてのチームメンバーの責任です。

統合テストを継続統合（CI）に含める必要があると思いますか？

合格する統合テストがあり、誰かが実際にそこに立ってボタンを押す必要がない場合は、はい-CIシステムに追加する必要があります。

ただし、統合テストの実行には非常に時間がかかるため、実行する頻度を制限する必要があります。CIサーバーがアイドル状態の夜間に実行できます。

最初にあなたの質問に答えます：はい、あなたが私に尋ねているなら、それらは間違いなく継続的インテグレーションの一部です。しかし、統合テストとは何かを明確にする必要があると思います。

Martin Fowlerは、完全なビルドプロセスを自動化して迅速に展開する方法として、継続的デリバリーについて話していました。これには、開発者が継続的インテグレーションプロセスによって提供される迅速なフィードバックを取得する必要があります。それで、彼はビルドが通過する段階を定義します：

1. コミットビルド
2. 徹底的なテスト
3. 配備

開発者への迅速なフィードバックのため、コミットビルドには10分以上かかることはありません。

物事の見方は次のとおりです。最初のステップでは、最新のコミットをフェッチしてビルドします。これが成功した場合、ユニットテストを実行して、クラス/クラスグループが定義どおりに機能しているかどうかを確認します。

これが成功すると、統合テスト部分に到達します。ここでは、正常にテストされたユニットの相互作用をテストします。これには、ユニットに入力を供給し、状態/相互作用/出力を監視することが含まれます。私たちはまだコミットビルドにいるので、これも高速にしたいことを覚えておいてください。そのため、迅速な実行のために、ファイルシステム、データベース、ネットワークピアなどとのやり取りをスタブする必要があります。Martin Fowlerは、CIサーバーでの実行を高速に保つために、必要に応じてインメモリデータベースを使用することも示唆しています。

ユニットが必要に応じて機能し、相互作用していることを確認したら、通常、テストカバレッジについて調べ（通常、小さなサブシステムをテストするだけでは不十分です）、テストされたアーティファクトを機能テスト/ QA /展開に利用できるようにします（読む：徹底的なテスト）テストで十分なプログラムがカバーされていると思われる場合。その直後に、ターゲットとする実稼働環境をミラーリングするテスト環境をプロビジョニングし、実際のデータベース、実際のファイル、実際のネットワークピアなどを含むテストを実行します。

結局、統合テストはコードの変更に関するものです。あなたが行った変更が現在のシステムを壊さないこと、つまりそれらがうまく統合されることを確認したいのです。それらが存在するかどうかを確認するには、それらが正しく動作することを確認し、依存関係と正しく対話し、テストされているかどうかを確認する必要があります。これらすべてのテストに合格した後は、システムについて静かに自信を持つことができます。

後の段階でプログラムに問題が見つかった場合（データベースが特定の値を返すときなど、ネットワーク接続が停止します）、統合テストでこれらのテストをスタブ化するようにしてください。ほとんどの場合、コミットビルドはQAよりも高速です;）