tdd – 你如何单元测试单元测试？

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

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

首先，测试就像安全性 – 你永远不能100％肯定你有它，但每层增加了更多的信心和框架，更容易解决仍然存在的问题。

其次，你可以将测试分解成子程序，然后再进行测试。当你有20个类似的测试，做一个(测试)子程序意味着你的主要测试是子程序的20个简单的调用，更可能是正确的。

第三，有些人会认为TDD解决这个问题。也就是说，如果你只是写了20个测试，他们通过，你不完全相信他们实际上是测试任何东西。但是如果你写的每个测试最初失败了，然后你修复它，那么你更有信心，它真的测试你的代码。 IMHO这种来回需要更多的时间比它的价值，但它是一个过程，尝试解决您的关注。

tdd – 你如何单元测试单元测试？

相关推荐