tdd - 如何对单元测试进行单元测试？

Question

我在 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);
}

现在测试有缺陷。显然在一个简单的测试中，这没什么大不了的，但是假设我们正在测试一个复杂的业务规则。我们在这里得到什么？

快进到应用程序的生命周期两年，此时维护开发人员正在维护它。现在业务改变了规则，测试再次失败，一些菜鸟开发人员错误地修复了测试......我们现在有另一个失败点。

我看到的只是更多可能的失败点，没有真正的 yield 返回，如果折扣价格错误，测试团队仍然会发现问题，单元测试如何节省工作量？

我在这里缺少什么？请教我爱上 TDD，因为到目前为止我很难接受它的有用性。我也想要，因为我想保持进步，但这对我来说没有意义。

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

Answer 1

首先，测试就像安全性一样 - 您永远无法 100% 确定自己已经掌握了它，但每一层都增加了更多的信心和一个框架，可以更轻松地解决仍然存在的问题。

其次，您可以将测试分解为子例程，然后可以对子例程本身进行测试。当您有 20 个类似的测试时，制作一个(已测试的)子例程意味着您的主要测试是对子例程的 20 次简单调用，这更有可能是正确的。

第三，有些人会认为 TDD解决了这个问题。也就是说，如果您只编写 20 个测试并且它们通过了，那么您并不完全确信它们实际上正在测试任何内容。但是，如果您最初编写的每个测试都失败，然后您修复了它，那么您就会更有信心它确实在测试您的代码。恕我直言，这种来回花费的时间比其值(value)要多，但这是一个试图解决您的担忧的过程。