开始使用 NUnit

安装 NUnit

要使用 NUnit 构建运行程序，您需要通过以下选项之一在 TeamCity 代理上安装 NUnit NuGet package：

• 指导第一步构建步骤从 NuGet 包中安装 NUnit。
  例如，您可以添加一个命令行构建步骤，该步骤将按照以下方式安装 NUnit.Console NuGet 包：

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

  请注意， % \teamcity.tool.NuGet.CommandLine.DEFAULT% 是指安装在 TeamCity 代理 下的 NuGet 的引用。
  您可以在 管理 | 工具 页面上为 agent 安装 NuGet，同时，您也可以在此页面上将任何已安装的 NuGet 版本标记为默认版本。

  之后， % \teamcity.tool.NuGet.CommandLine.DEFAULT% 参数引用应正确解析为代理上的 NuGet 安装路径。
  然后 nunit3-console 应出现在包目录下。

• 在所有构建代理上手动安装 NUnit 到标准位置，并在您的 NUnit 构建步骤中配置到 nunit-console.exe 的路径。

案例 1 命令行

从版本3开始，NUnit 开始支持 TeamCity 的开箱即用，这使得我们能够从命令行运行测试，并保留 TeamCity-NUnit 集成的基本特性。 NUnit 会自动检测是否由 TeamCity 运行，如果是，它会切换到集成模式。

除了自动检测功能，NUnit 3 控制台还处理特别的 --teamCity 参数，该参数还包括与 TeamCity 的集成。 此参数可用于调试目的，当您需要查看 NUnit 向 TeamCity 发送的什么信息时：详细的测试信息、测试的顺序等等。

使用 NUnit 控制台从命令行运行测试是最简单的方法。 TeamCity 提供了以下用于命令行的基本集成特性：

• 在测试执行时将测试运行信息报告在 Build Log 中

• 在测试结束后报告测试结果

• 所有的 TeamCity 调查功能

这就是 TeamCity 构建步骤运行命令行测试的样子：

总的来说，通过这个简单的案例，您可以使用 TeamCity-NUnit 3 集成的基础功能。

案例 2 MSBuild

此用例与前一个非常相似，但其目标是 MSBuild，这是 .NET 项目最广泛使用的构建平台。

TeamCity 支持开箱即用的代码覆盖率统计收集； 可以安装额外的插件，以在 TeamCity 中使用 安装 的 JetBrains dotTrace 和 JetBrains dotMemory Unit。

项目文件非常简单：运行的是Exec任务，其启动了测试：

NUnit 控制台返回失败的测试数量作为正的退出代码，如果 NUnit 测试基础结构失败，则为负的退出代码。

TeamCity 控制测试执行过程，但 NUnit 基础设施的异常可能不允许 TeamCity 收集所需信息。 这就是为什么需要设置 IgnoreExitCode="True" 属性，这将忽略正面的退出代码，而不会因多个失败的测试而中断构建。 如果测试基础设施出现错误导致负的退出代码，那么 Error 任务将终止构建。

除了项目文件外，您还可以定义 MSBuild 版本和目标平台，使用配置文件和其他设置。

为了使构建更稳定，您可以在项目文件中引入一些更改。 例如，您可以动态定义到 NUnit 控制台的路径。 NUnit 控制台 NuGet 包的更新可能会改变此路径，但我们的构建配置不需要做任何更改。 以下代码将 NUnit 控制台的路径获取到 pathToNUnitConsole 变量中：

您可以动态列出需要测试的程序集。 例如，您可以在特定的目录中搜索它们，并通过正则表达式模式进行筛选：

以下的项目文件包含了一些示例： sample2adv.proj，unit-utils.targets。

案例 3 NUnit 构建步骤

请注意，NUnit 运行器仅支持 .NET Framework。 为了运行 .NET Core 项目（以及 .NET Framework 项目版本 4.0 或更高版本）的测试，使用 .NET 构建运行程序，搭配 test 命令。 参考 NUnit Support 页面获取详细信息。

NUnit 构建步骤可能是在 TeamCity 中启动 NUnit 测试最简单，又最具有影响力的方式。
在大多数情况下，只需要设置两个参数：NUnit 控制台运行器的路径和需要测试的程序集列表。

NUnit runner 字段定义了用于运行测试的 NUnit 版本。 在为 NUnit 3 配置构建步骤时，Path to NUnit console runner 字段必须包含 NUnit 控制台的路径：请指定包含文件名的控制台可执行文件的路径。

在所有示例中，NuGet 包管理器都提供了 NUnit 基础设施。 使用 NuGet 可以让用户方便地管理测试环境，更新 NUnit ，并本地运行测试，就像它们将由 TeamCity 运行一样。

NUnit 构建步骤是在 TeamCity 中运行 NUnit 测试的一种直接且用户友好的方式。 它同时提供了最大范围的选项，通过使用 Mono 来隐藏在不同操作系统上运行测试的特定内容。

案例 4 NUnit 构建步骤，选项

在为 NUnit 3 配置 NUnit 构建步骤时，需要指定 NUnit Console 运行器（选择预装工具或输入自定义路径）。

其他字段提供了许多有用的选项，本节将讨论其中的一部分。

其中一种选择是定义 应用配置文件。 有时候，测试需要从配置文件中获取数据，为了方便这个过程，您需要在 应用配置文件路径 字段中定义运行测试时要使用的应用配置文件的路径。 路径可以是绝对的，也可以相对于 Build Checkout Directory。 遗憾的是，NUnit 的限制是每个构建步骤只允许一个配置文件。 由于这个限制，如果您需要在一个构建步骤中测试多个具有不同配置的程序集，您将必须将多个应用程序配置文件整合到一个公共配置文件中。 如果无法实现，将测试启动分解为几个步骤，并在每个步骤中定义一个配置文件。

NUnit 3 控制台具有大量由命令行参数定义的设置。 附加命令行参数 字段允许设置 NUnit 控制台的许多命令行参数，但存在一些限制：

• --where 命令行参数被用作优先测试过滤设置。 当它与 NUnit categories include 或/和 NUnit categories exclude 字段一起用于按类别筛选测试时，TeamCity 将忽略这些选项：将显示一个警告，只会使用 --where 参数。

• 在 额外的命令行参数 字段中使用以下参数可能会导致您的构建失败：

  • 待测试的程序集列表，因为由于命令行大小限制，NUnit构建步骤会从NUnit项目文件中确定程序集列表

  • NUnit 项目文件，因为 TeamCity 会创建其自己的临时 NUnit 项目文件（见 下面）

  • --工作 ：NUnit 构建步骤使用 构建检出目录 作为基础目录

  • --noheader 默认被使用

  • --x86 如果 .NET 运行时 | 平台 字段被设置为 x86

  • 如果 .NET 运行时 | 版本 设置为除 自动 之外的其他内容

  • 如果使用以下的算法

NUnit 构建步骤可以设为首先运行在之前构建中失败的测试。 这个观点是，它可以节省时间来推断完成构建的可能状态。 如果设置了 减少测试失败反馈时间 标志，只要前一个构建有失败的测试，就会按照三个步骤运行测试：

1. 作为第一步，TeamCity 考虑到按类别过滤（使用 --探索 控制台参数），获取所有程序集的测试列表，分析前一步运行的统计数据，并创建 2 个测试列表：优先列表和其余部分。 优先级列表包括在上次构建中失败的测试。

2. 在此步骤中，优先级测试将会运行。
3。 剩余的测试接下来。

NUnit 构建步骤的另一个优点是，它能在不同的操作系统上以相同的方式执行测试，无需更改配置。 如果代理所在地无法使用完整版本的 .NET ，但有 Mono ，那么这就对了。 它允许构建配置独立于操作系统。

调试 NUnit 测试

TeamCity 执行的所有操作，用户都可以在命令行中进行复现。 这使得快速有效地解决配置构建中可能出现的问题成为可能。

TeamCity 将所有与运行测试相关的数据记录到 构建日志 中。 因此，TeamCity 用于运行测试的命令可以从构建日志中复制，也可以在本地或者在代理上从命令行运行。

在运行测试时，除了命令外，TeamCity 还会创建临时文件：

• NUnit 项目文件

• JetBrains dotCover

• JetBrains dotTrace 或 JetBrains dotMemory Unit 配置文件

这些都包含在 hidden build artifacts 中。 例如，在构建日志中，用于启动 case 4 的测试的命令行将如下所示：

在这种情况下， 5Oqkbf9J2qJNkUK4KEtKvxs8TFFnlrno.nunit 是 NUnit 项目文件，您可以从 隐藏的构建工件下载：