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，因为我很难接受它到目前为止有用。我也想，因为我想保持进步，但它只是对我没有意义。

编辑：一对夫妇的人提到，测试有助于执行规范。根据我的经验，规范也是错误的，更常见的，但也许我注定要在一个组织工作，规范是由不应该编写规范的人写的。