单元测试 – 单元测试理念
我有一个“配方”方法,我试图用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年历史的代码库时它非常宝贵. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |