类似于TDD是否意味着不考虑课堂设计？,我无法思考传统的"设计"阶段适合TDD的地方.
根据保龄球游戏Kata("对话"版本,其链接逃脱了我的目前),TDD似乎忽略了早期做出的设计决定(丢弃框架对象,滚动对象等).我可以在这个例子中看到,遵循测试并忽略你最初的设计思路是一个好主意,但是在更大的项目或者你想要为扩展/定制留下空间的那些项目中,放入的东西不是更好您没有立即测试或不需要立即测试,以避免以后进行耗时的重写？
简而言之 - 在进行TDD时设计的数量是多少,在编写测试和传递它们的代码时我应该遵循该设计多少(忽略我的设计只是担心通过测试)？
或者我担心什么都没有,如果你被画到一个角落,那么简单地编写代码来编写代码并不是(在实践中)难以重写或重构？或者,我是否错过了这一点,当我来测试新的功能部分时,我应该期望重写部分代码？
我会根据您的初始设计进行测试.在许多方面,TDD是一个发现过程.您可以期望确认您的早期设计选择,或者发现您可以做出更好的选择.尽可能多地提前设计.有些人喜欢坐在椅子的座位上进行高级设计,并使用TDD来充实设计.而其他人则希望首先将所有东西都放在纸上.
TDD的一部分是重构.
关于"设计大型复杂系统"的内容应该与TDD无关 - 特别是当TDD被解释为"测试驱动设计"而不是"测试驱动开发"时.
在"开发"的上下文中,使用TDD将确保您编写可测试代码,该代码提供了有关TDD的所有好处(早期检测错误,高代码:测试覆盖率,更轻松的未来重构等)
但在"设计"大型复杂系统中,TDD并未特别解决系统架构中固有的以下问题
(即上述所有问题都不会通过"首先编写一个失败的测试用例,然后是工作实现,重构 - 泡沫,冲洗,重复..."配方)神奇地"出现".
对于这些,您需要通过在需求和问题空间所施加的约束下,对系统的高级细节和低级细节进行白板处理来解决问题.
上面的一些考虑因素相互竞争,需要通过编写大量的单元测试来进行仔细的权衡.
一旦定义和理解了关键组件及其职责,TDD就可用于实现这些组件.重构和不断审查/改进代码的过程将确保这些组件的低级设计细节精心设计.
我还没有遇到一个以测试驱动设计风格完成的非常复杂的软件(例如编译器,数据库,操作系统).以下博客文章非常好地讨论了这一点(编译器,TDD,掌握)
另外,请查看以下有关体系结构的视频,这些视频为思维过程增添了许多常识.
| 归档时间： |
|
| 查看次数： |
2436 次 |
| 最近记录： |