我正在使用带有 Microsoft 测试工具的 Visual Studio 2008。我需要从单元测试中访问一个文本文件。
我已经将构建操作设置为“内容”并复制到输出目录的文件配置为“始终复制”，但文件没有被复制到输出目录，根据System.Environment.CurrentDirectory 是
'{project_path}\TestResults\Pablo_COMPU 2009-11-26 15_01_23\Out'
这个文件夹包含了项目的所有DLL依赖，但是我的文本文件没有。
从单元测试中访问文本文件的正确方法是什么？
【问题讨论】：
标签： visual-studio visual-studio-2008 unit-testing
您必须将DeploymentItem 属性添加到您的测试类。使用此属性，您可以指定复制到 out 目录中以进行测试运行的文件。
例如：
[TestMethod]
[DeploymentItem(@"myfile.txt", "optionalOutFolder")]
public void MyTest()
{
...
}
【讨论】：
或者，如果您将所有文本文件设置为“复制到构建目录”，那么您可以通过这样做在测试中引用它们的路径
var directory = Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);
var path = System.IO.Path.Combine(directory, "myFile.txt");
【讨论】：
System.IO.Path.Combine() 而不是那个字符串连接。否则，这适用于单元测试场景。
当我需要一大段文本作为单元测试的一部分并且超过一两行时，我使用embedded resource。它不会弄乱您的测试代码，因为它是源代码中的一个单独的文本文件。它会直接编译到程序集中，因此您不必担心在编译后复制一个单独的文件。您的被测对象可以接受 TextReader，并且您传入通过加载嵌入资源获得的 StreamReader。
【讨论】：
由于我不使用 MSTest，因此无法回答您的问题。但是，我会考虑在单元测试中访问文件系统是否是正确的做法。如果你引入了对文件系统的依赖，测试会变得更慢，更不可信（你现在依赖的东西可能不存在/可访问/等）。正是由于这些原因，很多人会说“如果碰到文件系统就不是单元测试”。
虽然这不是硬性规定，但始终值得考虑。任何时候我必须在测试中接触文件系统时，我都会尽量避免它，因为我发现依赖文件的测试更难维护，而且通常不太一致。
我会在某种程度上考虑abstracting the file operations。你可以在这里做很多事情，从改变内部加载策略（通过依赖注入）到 - 甚至更好 - 分离文件的加载/使用，以便文件内容的使用者 甚至不必关心加载策略。
【讨论】：
您是如何进行测试的？
我们使用（TestDriven.net -> 运行测试）。
根据我的经验，一些测试运行程序（例如 Netbeans 中的 Junit）不会自动复制您可能需要进行测试的任何其他文本文件。因此，在您的情况下，您可能必须进行完整构建，然后再次尝试运行测试。
从测试中访问文本文件的正确方法是您尝试这样做的方式。 （将文件设置为“始终复制”和“内容”，并从编译目录访问它们）。
另外，不确定人们从哪里得到的想法是让测试依赖文件是一件坏事。不是。
如果有的话，拥有单独的测试文件只会清理您的测试并使它们更具可读性。考虑一些返回大字符串的 xml 解析方法：
String expectedOutput = fileOperator.ReadStringFromFile("expectedFileContents.xml");
String result = systemUnderTest.Parse(somethingtoparse);
Assert.Equals(expectedOutput, result);
想象一下，如果输出有 30 行长，你会用一个巨大的字符串弄乱你的测试代码吗？或者只是从文件中读取它。
【讨论】：