在第
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 the desired functionality.”
但是,在使用TDD时,我经常会为偶然行为编写测试.我该怎么办这些测试？抛弃它们似乎是错误的,但文章中的建议是这些测试可以降低敏捷性.
将它们分成单独的测试套件怎么样？这听起来像是一个开始,但直觉上似乎不切实际.有没有人这样做？
解决方法
根据我的经验,依赖于实现的测试很脆弱,并且在第一次重构时会大量失败.我尝试做的是在编写测试时专注于为类派生适当的接口,有效地避免接口中的这种实现细节.这不仅解决了脆性测试,而且还促进了更清洁的设计.
这仍然允许额外的测试,以检查我选择的实现的风险部分,但仅作为对我的类的“正常”接口的良好覆盖的额外保护.
对我来说,当我在考虑实施之前开始编写测试时,就会出现大的范式转变.我最初的惊喜是,生成“极端”测试用例变得更加容易.然后我认识到改进的界面反过来帮助塑造了它背后的实现.结果是我的代码现在没有比界面暴露更多的功能,有效地减少了对大多数“实现”测试的需求.
在重构类的内部时,所有测试都将成立.仅在暴露的接口发生更改的情况下,可能需要扩展或修改测试集.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
