我正在阅读Code Complete.在那本书中,Steve McConnell警告说"开发人员测试往往是'干净的测试'." 开发人员倾向于测试代码是否有效(干净测试),而不是测试代码中断的所有方式(脏测试).
如何编写代码中断方式的测试？我的意思是,我可以编写错误输入的测试,并确保它被正确阻止.但除此之外,我应该考虑哪些事情？麦康奈尔在这里意味着什么？我对基本的单元测试很满意,但试图掌握它.
我想你在这里走的是正确的道路.测试证明代码工作会调用具有合理,有意义和预期输入的方法,程序处于正常状态.虽然打破代码的测试试图考虑关于那段代码的"开箱即用",因此使用任何无意义或意外的输入.
恕我直言,重要的是了解两个思维过程是非常不同的.当开发人员以TDD方式编写代码时,他倾向于关注代码中要实现的各种功能,以及用于证明此功能或用例如指定工作的测试.以这种方式创建的测试是McConnell所说的"干净测试".
考虑如何破解一段代码需要一个非常不同的思考过程和不同的经验.它需要从不同的角度查看您的方法和API,例如暂时放下您对这些方法和参数的目标的了解,并仅关注技术上可能与它们做什么.还要考虑此方法正常工作所需的所有 - 通常是隐含的 - 前提条件或依赖项.它是否依赖于从DB读取的配置参数？它是否写入文件系统？它是否会调用另一个组件,期望它事先已正确初始化？它是否使用大量内存？它是否在GUI上显示消息？...如果其中一个或多个不成立,该怎么办？
所有这些都导致了一些重要问题:您的方法应该如何处理这些脏案？应该崩溃吗？抛出异常？尽可能继续？返回错误代码？记录错误报告？...所有这些小或大的决定对于正确一致地定义方法或API的合同实际上非常重要.
Kent Beck谈到了在同样意义上穿着"开发者帽子"和"测试帽"之间的转换.以这种方式流畅地切换观点和思维过程需要实践和经验.
| 归档时间： |
|
| 查看次数： |
691 次 |
| 最近记录： |