如何对单元测试进行单元测试？
我在MVCStoreFront应用程序上观看了Rob Connerys的网络广播，我注意到他甚至在对最平凡的事情进行单元测试，比如：
public Decimal DiscountPrice
{
get
{
return this.Price - this.Discount;
}
}会有一个类似这样的测试：
[TestMethod]
public void Test_DiscountPrice
{
Product p = new Product();
p.Price = 100;
p.Discount = 20;
Assert.IsEqual(p.DiscountPrice,80);
}虽然，我完全支持单元测试，但有时我想知道这种形式的测试优先开发是否真的有好处，例如，在真实的流程中，您在代码(业务请求、需求文档、体系结构文档)之上有3-4层，其中实际定义的业务规则(折扣价格是价格折扣)可能被错误定义。
如果是这种情况，那么您的单元测试对您来说毫无意义。
此外，您的单元测试是另一个失败点：
[TestMethod]
public void Test_DiscountPrice
{
Product p = new Product();
p.Price = 100;
p.Discount = 20;
Assert.IsEqual(p.DiscountPrice,90);
}现在这个测试是有缺陷的。显然，在一个简单的测试中，这没什么大不了的，但假设我们正在测试一个复杂的业务规则。我们在这里得到了什么？
快进到应用程序生命周期的两年，那时维护开发人员正在维护它。现在业务改变了它的规则，测试再次中断，然后一些新手开发人员修复了测试incorrectly...we，现在有了另一个故障点。
我所看到的是更多可能的故障点，没有真正有益的回报，如果折扣价格是错误的，测试团队仍然会找到问题，单元测试如何节省任何工作？
这里我漏掉了什么？请教我热爱TDD，因为到目前为止，我很难接受它是有用的。我也想要，因为我想保持进步，但这对我来说是没有意义的。
编辑:有几个人不断提到，测试有助于加强规范。根据我的经验，规范也是错误的，通常是错误的，但也许我注定要在一个规范由不应该编写规范的人编写的组织中工作。
回答 7
Stack Overflow用户
发布于 2009-01-08 15:22:13
Mutation testing是一种很有价值的技术，我个人用它取得了出人意料的好效果。有关更多详细信息，请阅读链接文章，并链接到更多学术参考，但通常它会通过修改源代码(例如，将"x += 1“更改为"x -= 1”)并重新运行测试来“测试您的测试”，确保至少有一个测试失败。任何不会导致测试失败的突变都会被标记出来，以便以后进行调查。
你会惊讶于你如何通过一组看起来全面的测试拥有100%的行和分支覆盖率，然而你可以从根本上更改甚至注释掉源代码中的一行，而不会有任何测试抱怨。这通常归结为没有使用正确的输入来测试所有边界情况，有时会更微妙，但在所有情况下，我都对它的结果印象深刻。
Stack Overflow用户
发布于 2008-10-28 18:46:33
大多数单元测试，测试假设。在这种情况下，折扣价格应该是价格减去折扣。如果你的假设是错的，我打赌你的代码也是错的。如果你犯了一个愚蠢的错误，测试将会失败，你会纠正它。
如果规则改变，测试将失败，这是一件好事。因此，在这种情况下，您也必须更改测试。
作为一般规则，如果测试立即失败(并且您不使用测试优先设计)，则测试或代码都是错误的(如果您遇到了糟糕的一天，则两者都有)。您可以使用常识(以及根据规范可能的情况)来更正违规代码并重新运行测试。
就像Jason说的，测试就是安全。是的，有时他们会因为错误的测试而引入额外的工作。但在大多数情况下，它们都能节省大量的时间。(你有一个绝佳的机会惩罚违反测试的人(我们说的是橡皮鸡))。
Stack Overflow用户
发布于 2008-10-28 18:43:00
尽你所能测试一切。即使是很小的错误，比如忘记将米转换为英尺，也会产生非常昂贵的副作用。写一个测试，写代码让它检查，让它通过，继续前进。谁知道在未来的某个时候，会不会有人更改折扣代码。测试可以检测到问题。
https://stackoverflow.com/questions/244345
复制相似问题