我有一个用TDD开发的非常重要的服务对象.它从一个简单的任务开始:对于队列中的对象,构造异步处理的尝试.所以我围绕我的constructAttempt()方法编写了一个测试:
void constructAttempt() {...}
有许多可能需要考虑的场景,所以我对这种方法进行了十几次测试.
然后我实现了我真正需要它做的事情:扫描整个队列并构建一批尝试.所以代码看起来更像:
public void go() { for (QueuedItem item : getQueuedItems()) { constructAttempt(item); } }
最后我发现我需要一些预处理,有时可能会影响constructAttempt().现在代码看起来更像:
public void go() { preprocess(); for (QueuedItem item : getQueuedItems()) { constructAttempt(item); } }
我对现在应该做些什么有些怀疑.
我应该保持代码不变,使用constructAttempt(),preprocess()和go()独立测试?为什么不是/为什么不呢?我冒险不承担预处理和破坏封装的副作用.
或者我应该重构整个测试套件只调用go()(这是唯一的公共方法)?为什么不是/为什么不呢?这会使测试更加模糊,但另一方面,它会考虑所有可能的相互作用.事实上,它将成为仅使用公共API的黑盒测试,这可能与TDD不符.
go方法实际上只是编排了几个交互,并且本身并不是很有趣.如果您针对go而不是从属方法编写测试,那么测试可能会非常复杂,因为您必须考虑preprocess和constructAttempt之间交互的组合爆炸(甚至可能是getQueuedItems,尽管听起来相对简单).
相反,您应该为下级方法编写测试 – 而constructAttempt的测试需要考虑所有预处理的潜在影响.如果您无法模拟这些副作用(通过操纵底层队列或测试双重),那么重构您的课程直到可以.
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。