Question

我正在使用VS2008 TFS（使用MSTest）。

我有一个可靠的单元测试，依赖于项目子文件夹中的数据文件（即testproject1 \ TestData）。数据文件属性是Build Action = Content，Copy Always。（它不是测试数据文件，而是生产代码读取并通常在其自己的文件夹中预期的文件）

构建并执行测试时，数据文件被正确复制到... \ TestResults \（testruniD）\ Out文件夹，测试代码会找到它。

现在，我将测试及其数据文件移动到解决方案中的另一个测试项目（它确实应该在那里），数据文件与新测试项目（testproject2 \ TestData）相同，并且检查数据文件属性仍然如上所述。但是在重建时，测试在新位置失败，因为数据文件尚未复制到测试结果输出文件夹，因此执行代码无法找到它。

我是否应该做些额外的工作来确保数据文件仍然被复制？

之前我遇到过相关的问题，一些数据文件被复制到测试结果输出文件夹中，而有些数据文件没有明显的原因，这让我感到困惑。

TIA

Answer 1

我知道这很晚。接受的答案在技术上是正确的。但是，多年来，我发现当数据文件过多时， DeploymentAttribute 方法变得很麻烦。就我而言，已接近一千。问题是

请记住将每个文件标记为复制到输出。
每次调试项目时，都会将数千个数据文件复制到 MyUnitTestProject \ Bin \ Debug 中。这减慢了我的整体开发和调试经验。

建议的解决方案

我提出的解决方案是让数据文件作为静态文件保留在单元测试项目中，并使用执行 System.Reflection.Assembly 的 Location 属性简单地确定绝对路径。 em>。考虑到我正在处理大量数据文件，这对我来说确实非常有效。当测试在 Jenkins 构建服务器上运行时，效果很好。

您可以参考我在另一个答案中发布的代码段。 NUnit DeploymentItem

建议的解决方案的缺点

您不会在每次运行测试时创建一个新的部署文件夹。如果您的单元测试将要创建输出文件，则您负责在单元测试程序集的位置下生成一个新文件夹，该文件夹通常为 MyUnitTestProject \ Bin \ Debug 。

在此处发布代码，因为我的超链接答案已删除 Martijn Pieters这个名字的人删除了我原来的答案，因为他不喜欢重复。因此，我在这里重现原始代码。

    internal static string GetFullPathToFile(string pathRelativeUnitTestingFile)
{
    string folderProjectLevel = GetPathToCurrentUnitTestProject();
    string final = System.IO.Path.Combine(folderProjectLevel, pathRelativeUnitTestingFile);
    return final;
}
/// <summary>
/// Get the path to the current unit testing project.
/// </summary>
/// <returns></returns>
private static string GetPathToCurrentUnitTestProject()
{
    string pathAssembly = System.Reflection.Assembly.GetExecutingAssembly().Location;
    string folderAssembly = System.IO.Path.GetDirectoryName(pathAssembly);
    if (folderAssembly.EndsWith("\\") == false) folderAssembly = folderAssembly + "\\";
    string folderProjectLevel = System.IO.Path.GetFullPath(folderAssembly + "..\\..\\");
    return folderProjectLevel;
}

Answer 2

使用DeploymentItem属性（more info here）。

编辑：根据OP，the .testrunconfig file must also be edited。

如何使数据文件可用于单元测试？

2 个答案: