相关疑难解决方法(0)

我在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,因为到目前为止我很难接受TDD.我也想要,因为我想保持进步,但这对我来说没有意义.

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