NUnit 理论取代测试？

Question

我见过很多关于理论的理论，但事实是，没有一个足以解释为什么不总是使用理论。我看不出有什么理由(除了……嗯……理论和测试这两个词不是同一个词)为什么不总是使用理论。

有趣的是，在所有示例中，您可以轻松地将测试设置为测试或理论，我确信我在这里遗漏了一些东西，但我不认为有必要让自己陷入哲学不确定性中关于我应该使用什么类型的属性。

假设差异只是为了自记录代码。那么，为什么使用 Datapoint 和 DatapointSource 进行理论，而使用其他东西进行测试？

事实是，我觉得没有人能给出一个简单明了的答案来阐明真正的差异所在。至少有一个例子，其中理论完全没有意义而测试非常适合，或者相反......

作为一名程序员，我......如果答案不简单，那就是有问题，所以......帮助我看看我缺少什么。

Answer 1

既然您指的是 NUnit，我将回答 WRT NUnit 的理论含义。请注意，这与 xUnit.Net 使用该术语的方式完全不同。

我从 JUnit，特别是 David Saff 的工作中获得了理论的想法。这是关于该主题的一篇论文:http://groups.csail.mit.edu/pag/pubs/test-theory-demo-oopsla2007.pdf谷歌“萨夫理论”，你会发现更多。

基本上，在创建测试时，您有时会对被测试的代码应该如何工作有一个理论。 (在这个答案中，小写理论是英文单词，而理论是 NUnit 的东西)这在数学推理中尤其常见。例如，考虑一个计算平方根的程序。我可以推测，任何非负数的平方根都是一个值，当它与自身相乘时，它会给出原始数。这是关于计算的完全独立的陈述。

使用 NUnit，我可以编写这样的测试......

public void SqrtTest(double value)
{
    Assume.That(value >=0 );
    double answer = SquareRootOf(value);
    Assert.That(answer*answer, Is.EqualTo(value));
}

无论我们给它什么数字，这个测试都有效。如果数字为负数，则结果不确定，不会影响整体结果。如果是肯定的，则执行实际断言，测试要么成功，要么失败。

在理想的世界中，提供的值可以来自任何地方。在 JUnit 中，它们来自数据点，我复制了它。我还允许程序员指定它们，主要作为临时解决方案。最终，我们的想法是测试框架将支持一系列为理论生成数据的方法，而无需程序员或测试人员的干预。

不幸的是，我们仍在等待最后一点。 :-)

底线，我认为当你有理论时你应该使用理论。当您只有示例而没有任何逻辑将它们绑定(bind)在一起时，请使用测试。 IME 这就是大多数业务应用程序中发生的情况。

有一天，我希望写一篇关于理论的很长的一章。