测试其他测试的最佳实践？

Question

开始编写单元测试(和其他类型的测试)时，我意识到一些测试(验收测试等)可能很快就会发展成相当复杂的软件，并且觉得可能会有一些单元测试(或者至少比原始测试更短的测试)来验证更长的测试可能已经到位。

“测试测试”听起来可能很愚蠢，但我想知道是否有人在实践这一点，是否有任何已知的最佳实践来进行“测试测试”？

Answer 1

测试测试生产代码，生产代码应该测试测试。;-)也就是说，你主要想测试的是它正确地测试了它想要测试的代码。要做到这一点，主要的方法是使代码出错，并查看测试是否捕获了它。

有一些工具可以自动执行此操作，并通过查看您可以对测试未捕获的代码进行哪些突变来测量测试覆盖率。参见Mutation Testing。

如果您的测试很复杂，那么您应该重构它们，并将一些复杂性提取到测试助手中。有了足够的这些，您最终可能会构建类似于测试框架的东西，这将值得测试。事实上，JUnit、RSpec、Cucumber、FitNesse等都是测试框架，并有测试套件来测试框架。

你应该试着让测试本身足够简单，让你相信它们能工作。但通过突变测试进行验证可能是值得的，特别是它还可以为您提供覆盖范围的度量。

Answer 2

不要测试测试。简单地假设他们是正确的，然后继续前进。

如果较低的测试失败，那么较高的测试当然也会失败。这是可以理解的。(我建议注意：“这个测试依赖于测试X、Y和Z的通过。”如果它不是直观的，可以快速浏览一下更高的测试。)但在继续之前，您不需要特定的测试来确保另一个测试有效-测试套件应该运行所有测试。

Answer 3

我认为如果你必须测试你的测试，你一定做错了什么。在我看来，测试应该非常简单和简单。然而，你能做的就是衡量你的测试有多好。也许你想知道你的测试有多大的代码覆盖率。但这并不是像你想的那样测试测试，不是吗？

无论如何，这可能是浪费时间..:)