请注意我还没有在TDD上看到"光明",也没有真正理解为什么它拥有主要支持者宣传的所有好处.我并没有解雇它 - 我只是保留了可能由于无知而产生的保留.所以无论如何都要嘲笑下面的问题,只要你能纠正我:-)
使用TDD会让您对实施的意外副作用持开放态度吗？"满足测试的最少量代码"的概念建议用最狭隘的术语思考特定问题,而不必考虑更大的图景.
我正在考虑持有或依赖于状态的对象(例如内部字段值).如果您有单独实例化对象的测试,初始化该对象然后调用测试中的方法,您会如何发现另一种方法留下了会对第一种方法的行为产生负面影响的无效状态？如果我已正确理解问题,那么您不应该依赖于测试执行的顺序.
我可以想象的其他失败包括非关闭流,不处理GDI +对象等.
这甚至是TDD的问题领域,还是整合和系统测试应该抓住这些问题？
在期待中感谢....
其中一些属于TDD领域.
Dan North说没有测试驱动开发这样的东西; 我们真正做的是示例驱动开发,只有在被测系统实现后,这些示例才会成为回归测试.
这意味着在设计一段代码时,您需要考虑示例场景并为每种情况设置测试.这些案件应包括的可能性,数据是无效的,没有考虑为什么数据可能是无效的.
在练习TDD时,可以并且绝对应该涵盖关闭流的内容.
我们使用类似函数的结构不仅可以减少重复,还可以封装功能.我们通过保持封装来减少副作用.我认为我们从设计角度考虑更大的图景,但是当涉及到实现方法时,我们应该能够将我们的重点缩小到该范围 - 功能单元.当我们开始玩弄外部性时,我们可能会引入缺陷.
无论如何,这是我的看法; 其他人可能会看到不同的
| 归档时间： |
|
| 查看次数： |
270 次 |
| 最近记录： |