インテグレーションの範囲CI CDワークフローでのテスト

Question

通常の/理想的なCIフローの基本的な理解とその中での統合テストの範囲の理解の問題です。私の理解あたりとして

、基本的なCIのCDフローだからユニットtetsingと統合テストを一括してビルドが安定して展開する準備ができているか確認します/決定

UnitTesting --> IntegrationTesting --> Build Artifact --> Deploy to Dev/Sandbox or any other subsequent environments. 

です。

しかし、最近私のチームで、デベロッパー/サンドボックスなどのデプロイされたインスタンスの統合テストを実行して、アプリケーションがデプロイメント後に正常に動作しているかどうかを検証したいと考えました。

Build-Deploy-Testワークフローのmicrosoft's articleは、これが可能性があることを示しています。

1. 統合テストは、異なる環境の設定をテストすることになっている - は：

   だから、私の質問をされますか？

2. アプリケーションのパッケージ化またはアプリケーションの展開の前に統合テストを実行する必要がありますか？
3. すべての環境で展開されたアプリケーションの機能をテストするには、何らかの自動テストが必要ですか？ 統合テストは、その後、他のソリューション

Answer 1

何ができるかあなたがSystem testingとの統合テストを混合していない場合。

コンポーネントが一緒に機能する（統合可能）ことを統合テストでチェックします。データレイヤAPIがデータベースとどのように動作するかを検証するための統合テストがあるかもしれません。またはWeb APIがHTTP呼び出しにどのように応答するかを示します。そのコンポーネントの統合テストを行うために、システム全体が完全に機能するとは限りません。

システムテストでは、統合テストとは異なり、すべてのコンポーネントを実装して構成する必要があります。これはエンドツーエンドのテスト（Webリクエストからデータベースレコードなど）です。この種のテストでは、システム全体を配備する必要があります。