单元测试 – 单元测试理念

我有一个“配方”方法,我试图用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调用上面传递的方法传递预期的参数,并在方法调用失败的情况下返回.
但这对我来说有点像这样一个巨大的投入时间来编写这样的测试,几乎没有实际的好处.

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

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

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

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

>您可能无法编写生产代码
直到你写了一个失败的
单元测试.
>你可能不会写更多的单元测试而不是足以失败,并且
不编译是失败的.
>您可能不会编写超过足以通过的生产代码
目前测试失败.

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

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

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

将单元测试添加到遗留代码是很困难的,但是可行并且非常值得付出努力.如果你还没有,我真的建议你在Michael Feathers之前阅读Working Effectively with Legacy Code.我发现将单元测试添加到一个已有25年历史的代码库时它非常宝贵.