单元测试 – 测试所需行为与TDD
发布时间：2020-12-14 04:56:05 所属栏目：百科 来源：网络整理
导读：在第 Test for Required Behavior,not Incidental Behavior条中,Kevlin Henney告诉我们： “[…] a common pitfall in testing is to hardwire tests to the specifics of an implementation,where those specifics are incidental and have no bearing on t
|
在第
Test for Required Behavior,not Incidental Behavior条中,Kevlin Henney告诉我们：
但是,在使用TDD时,我经常会为偶然行为编写测试.我该怎么办这些测试？抛弃它们似乎是错误的,但文章中的建议是这些测试可以降低敏捷性. 将它们分成单独的测试套件怎么样？这听起来像是一个开始,但直觉上似乎不切实际.有没有人这样做？ 解决方法
根据我的经验,依赖于实现的测试很脆弱,并且在第一次重构时会大量失败.我尝试做的是在编写测??试时专注于为类派生适当的接口,有效地避免接口中的这??种实现细节.这不仅解决了脆性测试,而且还促进了更清洁的设计.
这仍然允许额外的测试,以检查我选择的实现的风险部分,但仅作为对我的类的“正常”接口的良好覆盖的额外保护. 对我来说,当我在考虑实施之前开始编写测试时,就会出现大的范式转变.我最初的惊喜是,生成“极端”测试用例变得更加容易.然后我认识到改进的界面反过来帮助塑造了它背后的实现.结果是我的代码现在没有比界面暴露更多的功能,有效地减少了对大多数“实现”测试的需求. 在重构类的内部时,所有测试都将成立.仅在暴露的接口发生更改的情况下,可能需要扩展或修改测试集. （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |