NUnit 入門

NUnit のインストール

NUnit ビルドランナーを使用するには、次のいずれかのオプションを使用して TeamCity エージェントに NUnit NuGet パッケージをインストールする必要があります：

• 最初のビルドステップで、NuGet パッケージから NUnit をインストールするように指示します。

  例: 次のように、 NUnit.コンソール NuGet パッケージをインストールする コマンドラインビルドステップを追加できます。

  %\teamcity.tool.NuGet.CommandLine.DEFAULT%\tools\nuget.exe install NUnit.Console -version 3.6.0 -o packages

  %\teamcity.ツール.NuGet.CommandLine.DEFAULT% 文字列は、TeamCity エージェントにインストールされた NuGet への参照です。

  エージェントへの NuGet のインストールは 管理 | ツール ページで行えます。そこでは、インストール済みの NuGet バージョンのいずれかをデフォルトとしてマークすることもできます。

  その後、 %\teamcity.ツール.NuGet.CommandLine.DEFAULT% パラメーター参照は、エージェント上の NuGet インストールパスに正しく解決されるはずです。
  その後、nunit3-console はパッケージディレクトリの下に表示されるはずです。

• NUnit をすべてのビルドエージェントの標準の場所に手動でインストールし、NUnit ビルドステップで nunit-コンソール.exe へのパスを構成します。

ケース 1 コマンドライン

バージョン 3 以降、NUnit は TeamCity を標準でサポートしており、TeamCity-NUnit 統合の基本機能を維持したまま、コマンドラインからテストを実行できます。 NUnit は TeamCity によって実行されているかどうかを自動的に検出し、該当する場合は統合モードに切り替えます。

自動検出に加えて、NUnit 3 コンソールは TeamCity との統合も含まれる特別な --チームシティ 引数を処理します。 この引数は、詳細なテスト情報、テストの順序など、NUnit が TeamCity に送信する情報を確認する必要がある場合に、デバッグ目的で使用できます。

テストを実行する最も簡単な方法は、コマンドラインから NUnit コンソールを使用することです。 TeamCity は、コマンドライン向けに次の基本的な統合機能を提供します：

• テストの実行中にビルドログでテスト実行情報を報告する

• テスト終了時にテスト結果を報告する

• すべての TeamCity 調査機能

コマンドラインからテストを実行する TeamCity ビルドステップは次のようになります：

まとめると、この簡単なケースでは TeamCity-NUnit 3 統合の基本機能を使用できます。

ケース 2 MSBuild

この使用例は以前のものと非常に似ていますが、.NET プロジェクトで最も広く使用されているビルドプラットフォームである MSBuild を対象としています。

TeamCity は、コードカバレッジ統計の収集を初期状態でサポートしています。TeamCity で JetBrains dotTrace と JetBrains dotMemory Unit を使用するには、追加のプラグインを インストールできます。

プロジェクトファイルは単純です。テストを起動する Exec タスクが実行されます：

NUnit コンソールは失敗したテストの数を正の終了コードとして返し、NUnit テストインフラストラクチャの障害の場合は負の終了コードとして返します。

TeamCity はテスト実行の進捗を制御しますが、NUnit インフラストラクチャの例外により、TeamCity が必要な情報を収集できない場合があります。 そのため、 終了コードを無視="True" 属性を設定する必要があります。これにより、正の終了コードが無視され、いくつかのテストが失敗してもビルドは中断されません。 Error タスクは、負の終了コードに対するテストインフラストラクチャエラーが発生した場合にビルドを停止します。

プロジェクトファイルに加えて、MSBuild バージョンとターゲットプラットフォームを定義し、プロファイルとその他の設定を使用できます。

ビルドをより安定させるために、プロジェクトファイルにいくつかの変更を加えることができます。 例: NUnit コンソールへのパスは動的に定義できます。 このパスは NUnit コンソールの NuGet パッケージのアップデートによって変更されるかもしれませんが、私たちのビルド設定は何の変更も必要としません。 以下のコードは、 NUnit コンソールへのパス 変数への NUnit コンソールへのパスを取得します。

テストするアセンブリを動的にリストできます。 例: 特定のディレクトリで検索し、正規表現パターンに一致するようにフィルターします。

次のプロジェクトファイルにはいくつかの例が含まれています: サンプル2上級.proj (英語)、 ユニット-utils.targets (英語)。

ケース 3 NUnit ビルドステップ

NUnit ランナーは .NET フレームワークのみをサポートすることに注意してください。 .NET Core プロジェクト（および .NET フレームワークプロジェクトバージョン 4.0 以降）のテストを実行するには、代わりに テスト コマンドで .NET ビルドランナーを使用します。 詳細は NUnit のサポートのページを参照してください。

NUnit ビルドステップは、TeamCity で NUnit テストを起動するための、おそらく最もシンプルでありながら最も強力な方法です。
ほとんどの場合、設定する必要があるのは 2 つのパラメーターのみです：NUnit コンソールランナーへのパスと、テスト対象のアセンブリのリストです。

NUnit ランナー フィールドは、テストの実行に使用する NUnit バージョンを定義します。 NUnit 3 のビルドステップを設定する場合、 NUnit コンソールランナーへのパス フィールドには NUnit コンソールへのパスを含める必要があります。ファイル名を含むコンソール実行可能ファイルへのパスを指定してください。

すべての例で、NuGet パッケージマネージャーは NUnit インフラストラクチャを提供します。 NuGet を使用すると、テスト環境を簡単に管理し、NUnit を更新し、TeamCity で実行されるのと同じようにテストをローカルで実行できるようになります。

NUnit ビルドステップは、TeamCity で NUnit テストを実行するためのわかりやすく使いやすい方法です。 Mono(英語) を使用して、異なる OS で実行中のテストの詳細を同時に隠すオプションの最大範囲を提供します。

ケース 4。 NUnit ビルドステップ、オプション

NUnit 3 の NUnit ビルドステップを構成する場合、NUnit コンソールランナーを指定する必要があります（プリインストールツールを選択するか、カスタムパスを入力します）。

他のフィールドはたくさんの便利なオプションを提供し、このセクションはそれらのいくつかを論じます。

オプションの 1 つは、 アプリケーション構成ファイル を定義することです。 テストでは構成ファイルからデータを取得する場合があり、これを容易にするために、 アプリケーション構成ファイルへのパスフィールドでテストを実行するときに使用するアプリケーション構成ファイルへのパスを定義する必要があります。 パスは絶対パス、または ビルドチェックアウトディレクトリ からの相対パスにできます。 残念ながら、NUnit では、ビルドステップごとに 1 つの構成ファイルしか許可されないという制限があります。 この制限により、1 つのビルドステップで異なる構成を持つ複数のアセンブリをテストする必要がある場合は、複数のアプリケーション構成ファイルを共通の構成ファイルに集約する必要があります。 それが不可能な場合は、テストの起動を複数のステップに分割し、各ステップで構成ファイルを定義します。

NUnit 3 コンソールには、コマンドライン引数で定義された多数の設定があります。 追加のコマンドラインパラメーターフィールドでは、NUnit コンソールのコマンドラインパラメーターの多くを設定できますが、いくつかの制限があります。

• --条件 コマンドライン引数は、優先テストフィルター設定として使用されます。 カテゴリでテストをフィルターするために NUnit カテゴリを含める フィールドまたは/および NUnit カテゴリを除外する フィールドと同時に使用すると、TeamCity はこれらのオプションを無視します：警告が表示され、 --条件 引数のみが使用されます。

• 追加のコマンドラインパラメーターフィールドで以下のパラメーターを使用すると、ビルドが失敗する可能性があります。

  • コマンドラインのサイズ制限のため、NUnit ビルドステップで NUnit プロジェクトファイルからアセンブリのリストが決定されるため、テストするアセンブリのリスト

  • TeamCity は独自の一時 NUnit プロジェクトファイルを作成するため、NUnit プロジェクトファイル (以下を参照)

  • --作業 ：NUnit ビルドステップは ビルドチェックアウトディレクトリ をベースディレクトリとして使用します

  • --ヘッダーなし がデフォルトで使用されます

  • .NET ランタイム | プラットフォームフィールドが x86 アーキテクチャ に設定されている場合は --x86

  • .NET ランタイム | 版が 自動 以外に設定されている場合は --フレームワーク

  • 以下のアルゴリズムが使用されている場合は --詳しく見る

NUnit ビルドステップは、以前のビルドで失敗したテストを最初に実行するように設定できます。 アイデアは、完成したビルドの可能性のある状態について結論を出す時間を節約するということです。 テスト失敗のフィードバック時間を短縮フラグが設定されている場合、前のビルドがテストに失敗した場合、テストは 3 つのステップで実行されます。

1\. 最初のステップとして、TeamCity は、カテゴリ別のフィルターを考慮してアセンブリのすべてのテストリストを取得し (--詳しく見る コンソール引数が使用されます)、前のステップ実行の統計が分析され、2 つのテストリストが作成されます：優先リストと残りです。 優先リストには、前のビルドで失敗したテストが含まれます。

2\. このステップでは、優先テストが実行されます。
3\。 残りのテストが続きます。

NUnit ビルドステップのもう 1 つの優れた機能は、構成を変更せずに、異なる OS で同じ方法でテストを実行するという事実です。 これは、本格的な .NET が利用できないエージェントが Mono(英語) を持っている場合に当てはまります。 ビルド構成を OS に依存しないようにすることができます。

NUnit テストのデバッグ

TeamCity がテストの実行のために行うすべてのアクションは、コマンドラインで再現できます。 これにより、ビルドの構成に関する潜在的な問題を迅速かつ効果的に解決できます。

TeamCity は、テストの実行に関連するすべてのデータを ビルドログに記録します。 そのため、TeamCity がテストの実行に使用するコマンドはビルドログからコピーでき、ローカルまたはエージェント上のコマンドラインから実行できます。

テストの実行時、TeamCity はコマンドに加えて一時ファイルを作成します：

• NUnit プロジェクトファイル

• JetBrains dotCover

• JetBrains dotTrace または JetBrains dotMemory ユニット構成ファイル

これらは 非表示のビルドアーティファクトに含まれています。 たとえば、 ケース 4 のテストを起動するコマンドラインは、ビルドログで次のように表示されます。

この場合、 5Oqkbf9J2qJNkUK4KEtKvxs8TFFnlrno.nunit は NUnit プロジェクトファイルであり、 非表示のビルドアーティファクトからダウンロードできます。