测试单元测试辅助方法

时间:2014-12-31 10:56:56

标签: unit-testing testing tdd

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

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

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

我想知道这听起来是不错的做法,人们是否已经这样做过,是否对此有任何建议,是否指出了糟糕的设计,或类似的事情。

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

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

对这种做法有任何想法或意见吗?

3 个答案:

答案 0 :(得分:1)

我认为自己测试测试太过分了。 alfasin对,谁会测试测试测试呢?你不能在这个主题上找到很多信息并非巧合。这是因为它不是一种常见的做法。通常,精心编写的测试应涵盖测试本身的排列逻辑。但我理解你的愿望 - 如何确保测试是"写得好"?这里最危险的事情是通过测试,通常应该失败(但由于其中的错误而通过)。进行这样的测试甚至比完全没有测试更糟糕。但说实话,我在实践中并没有太多这样的案例。我的建议只是专注于编写涵盖逻辑的所有执行路径的良好测试,我认为你会没事的。)

答案 1 :(得分:1)

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

答案 2 :(得分:1)

虽然听起来有些不合常理,但我偶尔会为我的一些测试基础设施编写自动化测试,如果它变得相当复杂。测试这个测试基础设施的测试往往很简单,所以测试测试的测试结果如何?"根据我的经验,问题变得毫无意义。

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

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