单元测试理念

Question

我有一个"配方"方法,我试图用TDD编写.它基本上会调用不同的方法,偶尔会根据这些方法的结果做出决策:

  public void HandleNewData(Data data)
  {
     var existingDataStore = dataProvider.Find(data.ID);
     if (data == null)
        return;

     UpdateDataStore(existingDataStore, data, CurrentDateTime);

     NotifyReceivedData(data);

     if (!dataValidator.Validate(data))
        return;

     //... more operations similar to above
  }

我的膝跳反应将是开始编写测试用例,我在其中验证HandleNewData调用上面传递的方法传递预期的参数,并在方法调用失败的情况下返回.但这对我来说有点像这样一个巨大的投入时间来编写这样的测试,几乎没有实际的好处.

那么编写这样的测试真正的好处是什么？还是真的不值得打扰？

看起来它只是一个过度规范的代码,并且只要代码必须调用另一个方法或决定不再调用当前方法之一,就会导致维护问题.

Answer 1

TDD并不意味着为已经存在的代码编写单元测试(尽管有时在改进遗留代码时可能是必要的).

你可能听说过"Red,Green,Refactor"这个词.这是我们在进行TDD时采用的方法.以下是测试驱动开发的三个定律,它们更进一步......

1. 在编写失败的单元测试之前,您可能不会编写生产代码.
2. 你可能不会写更多的单元测试而不是足以失败,而不是编译失败.
3. 您可能不会编写超过足以通过当前失败测试的生产代码.

采用这种方法的好处是,您最终得到非常接近100%的单元测试覆盖率,并且您知道您的代码完全按照指定的方式工作.

它将减少维护问题,因为一旦有人对您的代码进行了更改并运行测试,他们就会知道他们是否已经破坏了任何东西.

在这种情况下,我会HandleNewData()在添加任何for之前逐步添加被调用方法的单元测试HandleNewData().

将单元测试添加到遗留代码是很困难的,但是可行并且非常值得付出努力.如果你还没有,我真的建议你阅读与遗留代码一起工作,有效的迈克尔羽毛.我发现将单元测试添加到一个有25年历史的代码库时它非常宝贵.