使用 AsConfigured 并且仍然能够在 TFS 中获得 UnitTest 结果答案

【问题标题】：Using AsConfigured and still be able to get UnitTest results in TFS使用 AsConfigured 并且仍然能够在 TFS 中获得 UnitTest 结果
【发布时间】：2014-08-04 04:11:23
【问题描述】：

所以当我使用输出位置“AsConfigred”使用 tfs 构建控制器构建我的项目时遇到了一个问题，它不会检测到我的单元测试。让我提供一些关于我的设置的信息。

TFS 2013 更新 2，默认进程模板

这里有一些屏幕截图，希望可以帮助填补我无法输入的内容。我正在将我的构建复制到我们网络上的文件共享中，以便我们可以使用其他实用程序来使用输出。我不想使用“PerProject”或“SingleFolder”，因为它们会弄乱我们配置的文件结构（它们都将运行测试）。所以我将文件复制到文件夹名称“SingleOutputFolder”，它是 DropLocation 的子文件夹。我希望能够从放置文件夹运行或从 bin 文件夹运行我的每个测试（我不在乎哪个）。但是，它似乎没有检测/运行任何测试。任何帮助将不胜感激。如果您需要任何其他信息，请告诉我。

我尝试过使用 ***test*.dll、Install\SingleFolderOutput**.test.dll 和 $(TF_BUILD_DROPLOCATION)\Install\SingleFolderOutput*test*.dll

但我不确定有哪些变量可用，也不知道它的执行范围在哪里。

【问题讨论】：

标签： unit-testing tfs mstest tfsbuild

【解决方案1】：

鉴于您使用 Build Output location 设置为 AsConfigured，您必须将 Test sources spec 设置的默认值更改为允许 build 在 bin 文件夹中查找测试库。这是一个例子。

如果单元测试库的完整路径是：

E:\Builds\7\<TFS Team Project>\<Build Definition>\src\<Unit Test Project>\bin\Release\*test*.dll

使用

..\src\*UnitTest*\bin\*\*test*.dll;

【讨论】：

我有一些我想忽略的集成测试，所以我使用了..\src\*.test\bin\*\*.test.dll
我也想在子目录中搜索，而不仅仅是直接在 src 下。 ..\src\**\*test*.dll 会这样做，但每次测试都会找到两次，大概是因为它同时找到了 bin\Debug\test.dll 和 obj\Debug\test.dll。我试过..\src\**\bin\*\*test*.dll，但什么也没找到。除了破解 XAML 之外，还没有找到完整的解决方案

【解决方案2】：

这个问题是在 MSDN 论坛 here 上提出的。

MSDN 论坛建议的解决方法

接受的答案中建议的解决方法（截至 6 月 20 日上午 8 点）是指定测试项目二进制文件夹的完整路径：例如：

C:\Builds\{agentId}\{teamProjectName}\{buildDefinitionName}\src\{solutionName}\{testProjectName}\bin*\Debug\*test*.dll*

确实应该显示为

{agentWorkingFolder}\src\{relativePathToTestProjectBinariesFolder}\*test*.dll

但是这种方法非常脆弱，原因如下：

在将它们添加到构建定义的测试源列表之前，您添加到解决方案中的任何新测试项目都不会执行：
在以下任何一种情况下都会中断：
- 构建定义已重命名
- 构建代理属性中的工作文件夹已修改
- 您有多个构建代理，并且与您在 {id} 中指定的代理不同的代理运行构建

改进的解决方法

我的解决方法可以缓解 #2 中列出的问题（对 #1 无能为力）。

在上面指定的路径中，替换开头部分：

{agentWorkingFolder}

与

..

所以你有

..\src\{relativePathToTestProjectBinariesFolder}\*test*.dll

这是因为内部工作目录显然是 \binaries\ 文件夹，它是 \src\ 文件夹的兄弟。在指定测试项目二进制文件的路径之前，向上导航到父文件夹（无论它的名称如何，我们都不关心）并返回到 \src\。

注意：如果您有多个测试项目，请添加其他条目，用分号分隔：

..\src\{relativePathToTestProjectONEBinariesFolder}\*test*.dll;..\src\{relativePathToTestProjectTWOBinariesFolder}\*test*.dll;..\src\{relativePathToTestProjectTHREEBinariesFolder}\*test*.dll;

【讨论】：

如果您有多个构建配置，例如构建和调试，这将不起作用。由于您必须指定确切的路径，因此它将为两个构建运行调试测试。
@Deli，您能否设置两个不同的构建定义，一个用于您的发布构建，另一个用于调试构建？然后每个构建定义都应该指定自己的一组测试二进制文件。这听起来很烦人，但大多数解决方法都是。
是的，它应该可以工作，只是需要多一点时间，因为代码需要检查两次。
这个..\src\**\*test.dll 为我工作，无需指定项目（如果它符合您的需要）。
我为 X64 平台设置了“AsConfigured”设置，无需该开关即可将二进制文件放入 src\x64\Release\` (and it used to place them into bin\x64\Release\`）。所以，我最终使用..\..\..\src\**\*test*.dll 作为我的“测试源规范”。

【解决方案3】：

我最终做的是添加一个构建后事件，将所有 test.dll 复制到特定构建中的 staging location 文件夹中，这基本上等同于它在 SingleFolder 构建中的位置并在每个构建中执行此操作测试项目。

if "$(TeamBuildOutDir)" == "" (
echo "Building Interactively not in TFS"
) else (
echo "Building in TFS"
xcopy "$(TargetDir)*.*" "$(TeamBuildBinaries)\" /Y /E /S
)

构建定义中的 MSBUILD 参数告诉它基本上放入 TFS 查找它们的文件夹中。

/p:TeamBuildBinaries="$(TF_BUILD_BINARIESDIRECTORY)"

保留默认的测试程序集文件规范：

**\*test*.dll

查看此链接以获取有关我使用的变量及其存在的相对路径的信息。

【讨论】：

【解决方案4】：

另一种解决方案是反其道而行之。

将所有文件保留在根目录中，以便所有内置功能都能正常工作。那里不仅仅是测试执行。静态代码分析、影响分析……等等。你必须为他们做一些定制的事情。

改为使用 pre-drop powershell 脚本从根文件创建您的安装安排。

如果它是一个应用程序，那么您可以使用 _ApplicationFolder Nuget 包创建一个 _PublishApplications 文件夹，就像您为 Web 应用程序获取的一样。

【讨论】：