【问题标题】:Testing unit tests' helper methods测试单元测试的辅助方法
【发布时间】:2014-12-31 10:56:55
【问题描述】:

在我编写测试时,其中一些包含很多逻辑。大多数逻辑都可以很容易地进行单元测试,这将在测试中提供更高级别的信任。

我可以看到一种方法来做到这一点,那就是创建一个类 TestHelpers,放入 /classes,并为 TestHelpers 编写测试以及常规测试。

我在网上找不到任何关于这种做法的意见,可能是因为问题的关键字很棘手(“测试测试”)。

我想知道这听起来是否是好的做法,人们是否已经这样做了,是否有任何建议,这是否指向糟糕的设计,或类似的东西。

我在进行特性测试时遇到了这个问题。我知道它有一些框架,但我是自己编写的,因为它并不复杂,而且它让我更加清晰。另外,我可以想象在单元测试中很容易遇到同样的问题。

举个例子,在某个时候,我正在测试一个连接到 Twitter 的 API 服务并检索一些数据的函数。为了测试数据是否正确,我需要测试它是否是一个 json 编码的字符串,结构是否与 twitter 的数据结构匹配,每个值是否具有正确的类型等。执行所有这些检查的函数与检索到的数据单独测试通常会很有趣。

对这种做法有什么想法或意见吗?

【问题讨论】:

  • 什么会测试你的测试? :)

标签: unit-testing testing tdd


【解决方案1】:

关于 TDD 的格言之一是“测试测试代码,代码测试测试”。也就是说,由于红-绿-重构循环,您会看到代码未通过测试,然后在使其工作后,您会看到它通过了测试——仅此一项就足以让您对测试(以及它调用的所有测试实用程序代码)都可以正常工作。对于表征测试,您没有这个红-绿-重构循环,因此为您的测试实用程序方法编写测试可能对您很有价值。

【讨论】:

    【解决方案2】:

    我认为自己测试测试太多了。 alfasin 对,那么谁会为测试进行测试呢?您找不到有关此主题的太多信息并非巧合。那是因为这不是一种常见的做法。通常,编写良好的测试应该涵盖测试本身的排列逻辑。但我理解你的愿望——如何确保测试“写得好”?这里最危险的事情是通过测试,通常应该失败(但由于其中的错误而通过)。有这样的测试比根本没有测试还要糟糕。但老实说,我在实践中并没有太多这样的案例。我的建议是专注于编写涵盖逻辑的所有执行路径的良好测试,我认为你会没事的 :)

    【讨论】:

      【解决方案3】:

      虽然这听起来很反常,但我有时会为我的一些测试编写自动化测试infrastructure如果它变得相当复杂。测试这个测试基础设施的测试往往很简单,所以“为测试测试测试怎么样?”根据我的经验,这个问题变得没有实际意义。

      请注意,这主要发生在一个专门设计用于帮助其他人(在这种情况下是编写 Qt 应用程序的人)测试的库中,尽管我之前已经为一些独立应用程序这样做过:例如,在编写测试时对于 Kate 的 Vim 模式的自动完成集成,用于模拟各种配置的自动完成的虚假自动完成程序测试助手代码变得足够复杂,以至于我实际上开始先测试开发它。

      可能值得一提的是,例如Google Mock 为其编写了数百个测试:)

      【讨论】:

        猜你喜欢
        • 2010-12-24
        • 2013-03-06
        • 2011-06-20
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多