Question

[TestMethod]
public void SomeTestMethod()
{
    string input = "some looooong input...";

    var proc = new Processor()
    string result = proc.DoSomething(input);

    Assert.Equals("good", result);
}

如果我正在编写单元测试并且输入的时间非常长（例如EDI事务），那么我应该将其作为长字符串粘贴到我的测试方法中吗？

其他人建议我将该长字符串粘贴到文件中，并将该文件视为我的测试项目中的嵌入式资源。如果我做了类似的事情，我需要为每个测试提供不同的输入，我可以看到很多文件堆积起来并变得难以维护。

有没有围绕这个的最佳做法？我应该继续将这些长字符串粘贴到我的测试方法中吗？

Answer 1

我总是将长测试字符串放入资源中，并在测试及其资源之间保持一致的命名，以保持映射的简单性。我为资源和测试使用相同的名称。当我需要多个资源进行测试时，我会添加后缀1，2，3，等等。

Answer 2

您可以使用不同的字符串构造函数来创建一个非常长的重复字符串，例如：

string input = new string('x', 1024 * 1024 / 2);

这种方法提供了一种更优雅的方法来创建长字符串，而不必将长字符串粘贴到测试中。

Answer 3

我正在测试一些针对文件的正则表达式。我做的是我将文件的内容复制粘贴到测试类中作为普通属性，但我使用#region标签来隐藏它。每次打开测试类时，我都不需要看到200行文本。这也是我发现#region标签有用的少数情况之一。

Answer 4

在不知道Processor代码的情况下，Processor应该有简单，快速的单元测试来覆盖其内部工作，而像SomeTestMethod这样的测试应该被视为< strong>集成测试。

因此，我会将所有测试数据存储在XML文件中，并将其加载到测试中，为每个输入运行相同的测试（如果您希望测试大量数据 - 您可以使用数据库）。没有必要为每个输入编写单独的测试。

描述了here中关于如何在MSTest中完成此操作的非常干净和优雅的方法。

Answer 5

如果它的内容很快我不关心我把它放在代码中。因为我很可能会测试一个概念。

如果您的代码要像测试或生产代码一样保留，那么请将资源文件用作嵌入式资源或使用resx文件，这对您来说更为舒适。

Answer 6

这只是一个“自以为是”的答案，因为我从未见过有关此问题的最佳做法;

我使用EDI文件，我们的测试用例通常是自包含的粘贴测试数据，就像你做的那样，在我们的例子中是在测试本身之外定义的常量，以免混淆实际的测试代码。

我们发现外部文件的处理本身就容易出错。

长输入的单元测试

6 个答案: