我已经看过很多关于理论的理论，但事实是，它们都不足以解释为什么不总是使用理论。我没有看到一个理由（除了...嗯......理论和测试这两个词不是同一个词）为什么不总是使用理论。
有趣的是，在所有的例子中，你可以轻松地将你的测试设置为测试或理论，我相信我在这里遗漏了一些东西，但我认为没有必要把自己置于哲学的不确定性中关于我应该使用什么类型的属性。
我们假设差异仅仅是为了自我记录的代码。那么，为什么你使用Datapoint和DatapointSource for Theory和其他东西进行测试？
事实是，我觉得没有人能找到一个简单而干净的答案来点亮真正的差异。至少有一个例子，其中理论绝对没有意义，而且测试很合适，或者反过来......
作为一名程序员，我......如果答案不简单，那就有问题了......帮助我看看我错过了什么。
答案 0 :(得分：1)
既然你指的是NUnit，我将回答一下理论中NUnit意味着什么。请注意，这与xUnit.Net使用术语的方式完全不同。
我从JUnit获得了理论的想法，尤其是David Saff的工作。这里有一篇关于这个主题的论文：http://groups.csail.mit.edu/pag/pubs/test-theory-demo-oopsla2007.pdf Google“saff theory”，你会发现更多。
基本上，在创建测试时，您有时会有一个关于测试代码应该如何工作的理论。 （在这个答案中，小写理论是英语单词而理论是NUnit的东西）这在数学推理中尤为常见。例如，考虑一个计算平方根的程序。我可以推测，任何非负数的平方根都是一个值，使得它在乘以自身时给出原始数。这是关于计算的一个完全独立的陈述。
使用NUnit，我可以编写这样的测试...
public void SqrtTest(double value)
{
Assume.That(value >=0 );
double answer = SquareRootOf(value);
Assert.That(answer*answer, Is.EqualTo(value));
}
无论我们提供什么号码，此测试都有效。如果数字为负数，则结果不确定，不会影响总体结果。如果是肯定的，则执行实际的断言，测试成功或失败。
在理想世界中，提供的值可以来自任何地方。在JUnit中，它们来自Datapoints，我复制了它。我还允许他们主要作为临时解决方案进行程序员指定。最终，我们的想法是测试框架将支持一系列为理论生成数据的方法，而无需程序员或测试人员的干预。
不幸的是，我们仍在等待最后一点。 ： - ）
最重要的是，我认为你有理论时应该使用Theory。如果只有示例而没有任何逻辑将它们绑定在一起，请使用测试。 IME就是大多数商业应用程序中发生的事情。
有一天，我希望写一篇关于理论的长篇章。