【问题标题】:Unit testing with long inputs长输入的单元测试
【发布时间】:2012-01-06 16:42:03
【问题描述】:
[TestMethod]
public void SomeTestMethod()
{
    string input = "some looooong input...";

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

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

如果我正在编写一个单元测试并且我有一个非常长的输入(例如 EDI 事务),我应该将它作为一个长字符串粘贴到我的测试方法中吗?

其他人建议我应该将该长字符串粘贴到一个文件中,并将该文件视为我的测试项目中的嵌入式资源。如果我做这样的事情并且我的每个测试都需要不同的输入,我会看到很多文件堆积起来并且变得难以维护。

在这方面有什么最佳做法吗?我应该继续将这些长字符串粘贴到我的测试方法中吗?

【问题讨论】:

    标签: c# unit-testing


    【解决方案1】:

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

    【讨论】:

    • 这也将让 Intellisense 让您一窥资源 - 很酷
    【解决方案2】:

    您可以使用不同的字符串构造函数来创建一个很长的重复字符字符串,例如:

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

    这种方法提供了一种更优雅的方式来创建长字符串,而无需将长字符串粘贴到您的测试中。

    【讨论】:

    • 嗯,百万 x 在我看来不像 EDI 交易 :)
    • 是的,但是“一些 looooong 输入...”也没有。这可能是您需要使字符串的第一部分包含有效的标题信息,然后填充大部分使用诸如此类的方法的字符串。根据您需要测试的内容,这种方法可能不起作用,但如果您只需要非常长的东西,它确实提供了一种创建长字符串的好方法。
    【解决方案3】:

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

    【讨论】:

      【解决方案4】:

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

      因此,我会将所有测试数据存储在一个 XML 文件中,并将其加载到测试中,对每个输入运行相同的测试(如果您希望测试大量数据 - 您可以使用数据库)。无需为每个输入编写单独的测试。

      here 描述了如何在 MSTest 中完成此操作的非常简洁和优雅的方法。

      【讨论】:

        【解决方案5】:

        如果我不关心它的快速操作,我会将其放入代码中。因为我很有可能在测试一个概念。

        如果您要保留其代码类似于测试或生产代码,则使用资源文件作为嵌入式资源或使用 resx 文件,无论哪种方式您都更习惯。

        【讨论】:

          【解决方案6】:

          这只是一个“自以为是”的答案,因为我从未见过任何关于此的最佳实践;

          我使用 EDI 文件,我们的测试用例通常与您所做的一样包含粘贴的测试数据,在我们的示例中是在测试本身之外定义的常量,以免弄乱实际的测试代码。

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

          【讨论】:

            猜你喜欢
            • 1970-01-01
            • 1970-01-01
            • 2020-12-27
            • 1970-01-01
            • 2014-06-01
            • 2017-04-25
            • 2018-12-27
            • 1970-01-01
            • 1970-01-01
            相关资源
            最近更新 更多