最佳答案
如何对单元测试进行单元测试？
我在 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);
}
现在这个测试有缺陷了。显然，在一个简单的测试中，这没什么大不了的，但是假设我们正在测试一个复杂的业务规则。我们能得到什么？
当维护开发人员正在维护应用程序时，应用程序的生命周期快进了两年。现在业务改变了它的规则，而且测试再次打破，一些新手开发人员然后修复测试错误... 我们现在有另一个失败点。
我所看到的是更多可能的失败点，没有真正有益的回报，如果折扣价格是错误的，测试团队仍然会发现问题，单元测试如何节省任何工作？
我错过了什么？请教我去爱 TDD，因为到目前为止我很难接受它是有用的。我也想，因为我想保持进步，但这对我来说毫无意义。
编辑: 一些人一直提到测试有助于强制执行规范。根据我的经验，规格说明书也经常出错，但也许我注定要在一个规格说明书由不该编写规格说明书的人编写的组织中工作。
