テストの設定と実行

受講生用ラボマニュアル

ラボの要件

このラボには、Microsoft Edge または Azure DevOps 対応ブラウザーが必要です。
Azure DevOps 組織を設定する: このラボで使用できる Azure DevOps 組織がまだない場合は、組織またはプロジェクトコレクションの作成に関するページの手順に従って作成してください。

ラボの概要

変更に対応するとき、複雑なソフトウェアには予想外のエラーが発生することがあります。そのため、ほとんどの些細な (少なくとも重要性が最も低い) アプリケーションを除くすべてのアプリケーションで変更後のテストが必須となります。手動テストはソフトウェアのテスト方法として最も遅く、信頼性がなく、高額です。

ソフトウェアアプリケーションでは、さまざまな種類のテストが自動化されています。最も単純でレベルの低いテストが単体テストです。少し高いレベルに、統合テストや機能テストがあります。他の種類のテスト (UI テスト、ロードテスト、ストレステスト、スモークテストなど) は、このラボでは扱いません。

'’さまざまな種類のテストについて詳しく知りたい場合は、「ASP.NET Core MVC アプリのテスト」の記事を読むことをお勧めします。’‘**

目標

このラボを完了すると、以下を含む .Net アプリケーションの CI パイプラインを構成できるようになります。

単体テスト
統合テスト
機能テスト

推定時間:60 分

Instructions

演習 0:ラボの前提条件の構成

この演習では、ラボの前提条件を設定します。これは、eShopOnWeb に基づくリポジトリを含む新しい Azure DevOps プロジェクトで構成されます。

タスク 1: (完了している場合はスキップしてください) チームプロジェクトを作成して構成する

このタスクでは、複数のラボで使用される eShopOnWeb Azure DevOps プロジェクトを作成します。

ラボコンピューターのブラウザーウィンドウで、Azure DevOps 組織を開きます。 [新しいプロジェクト] をクリックします。プロジェクトに「eShopOnWeb」という名前を付け、他のフィールドは既定値のままにします。 [作成] をクリックします。

タスク 2: (完了している場合はスキップしてください) eShopOnWeb Git リポジトリをインポートする

このタスクでは、複数のラボで使用される eShopOnWeb Git リポジトリをインポートします。

ラボコンピューターのブラウザーウィンドウで、Azure DevOps 組織と、前に作成した eShopOnWeb プロジェクトを開きます。 [リポジトリ] > [ファイル] 、 [リポジトリをインポートする] をクリックします。 [インポート] を選択します。 [Git リポジトリをインポートする] ウィンドウで、URL https://github.com/MicrosoftLearning/eShopOnWeb.git を貼り付けて、 [インポート] をクリックします。
リポジトリは次のように編成されています。
- .ado フォルダーには、Azure DevOps の YAML パイプラインが含まれています。
- .devcontainer フォルダーには、コンテナーを使って開発するためのセットアップが含まれています (VS Code でローカルに、または GitHub Codespaces で)。
- infra フォルダーには、一部のラボシナリオで使用される Bicep および ARM のコードとしてのインフラストラクチャテンプレートが含まれています。
- .github フォルダーには、YAML GitHub ワークフローの定義が含まれています。
- src フォルダーには、ラボシナリオで使用される .NET Web サイトが含まれています。

演習 1: CI パイプラインでテストを設定する

この演習では、CI パイプラインでテストを設定します。

タスク 1: (完了している場合はスキップしてください) CI 用の YAML ビルド定義をインポートする

このタスクでは、継続的インテグレーションの実装に使う YAML ビルド定義を追加します。

まず、eshoponweb-ci.yml という CI パイプラインをインポートします。

[パイプライン] > [パイプライン] に移動します。
[新しいパイプライン] ボタンをクリックします。
[Azure Repos Git (YAML)] を選びます。
eShopOnWeb リポジトリを選びます。
[既存の Azure Pipelines YAML ファイル] を選びます。
メイン ブランチと /.ado/eshoponweb-ci.yml ファイルを選択し、[続行] をクリックします。

CI の定義は以下のタスクで構成されます。
- DotNet Restore: NuGet パッケージの復元を使うと、ソース管理に格納しなくても、プロジェクトのすべての依存関係をインストールできます。
- DotNet Build: プロジェクトとそのすべての依存関係をビルドします。
- DotNet Test: 単体テストの実行に使われる .Net テストドライバー。
- DotNet Publish: ホスティングシステムへのデプロイ用のフォルダーに、アプリケーションとその依存関係を発行します。この場合は、Build.ArtifactStagingDirectory です。
- 成果物の発行 - Web サイト: (前のステップで作成した) アプリ成果物を発行し、パイプライン成果物として利用できるようにします。
- 成果物の発行 - Bicep: インフラストラクチャ成果物 (Bicep ファイル) を発行し、パイプライン成果物として利用できるようにします。
[保存] ボタン ( [保存して実行] ではなく) をクリックして、パイプライン定義を保存します。

タスク 2: CI パイプラインにテストを追加する

このタスクでは、統合および機能テストを CI パイプラインに追加します。

単体テストタスクがパイプラインに既に含まれていることがわかります。

単体テストでは、アプリケーションのロジックの 1 つの部分をテストします。単体テストに含まれない内容を列挙するして単体テストをさらに説明できます。単体テストでは、依存関係やインフラストラクチャとのコードの連動をテストしません。それは統合テストの対象です。

次に、単体テストタスクの後に統合テストタスクを追加する必要があります。
```
 - task: DotNetCoreCLI@2
   displayName: Integration Tests
   inputs:
     command: 'test'
     projects: 'tests/IntegrationTests/*.csproj'
```
統合テストでは、コードが依存関係またはインフラストラクチャとどのように連動するかをテストします。データベースやファイルシステムなど、インフラストラクチャとやり取りするコードをカプセル化することは良い考えですが、それでもカプセル化されないコードが残るので、それをテストすることになります。また、アプリケーションの依存関係が完全に解決されるとき、コードの層が予想どおりにやり取りすることを検証してください。この機能は統合テストの担当です。
次に、統合テストタスクの後に機能テストタスクを追加する必要があります。
```
 - task: DotNetCoreCLI@2
   displayName: Functional Tests
   inputs:
     command: 'test'
     projects: 'tests/FunctionalTests/*.csproj'
```
機能テストはユーザーの視点から記述され、その要件に基づき、システムの正確性を検証します。システムの一部のコンポーネントが正しく連動することを検証する目的で、開発者の視点から記述される統合テストとは異なります。
[保存] をクリックし、 [保存] ペインでもう一度 [保存] をクリックして、メインブランチに変更を直接コミットします。

タスク 4: テストの概要を確認する

[実行] をクリックし、 [パイプラインの実行] タブで [実行] をもう一度クリックします。
パイプラインが開始され、ビルドステージが正常に完了するまで待ちます。
完了すると、パイプラインの実行の一部として [テスト] タブが表示されます。それをクリックして概要を確認します。以下のように表示されます。
詳細については、ページの下部にあるテーブルにさまざまなテストの実行のリストが示されています。

注: テーブルが空の場合は、フィルターをリセットして、テストの実行に関するすべての詳細が示されるようにする必要があります。

確認

このラボでは、Azure Pipelines と .Net を使用してさまざまなテストの種類をセットアップして実行する方法について学習しました。