我的理解是TDD应该这样
>编写我将要开发的接口/类的测试列表.
>从我的测试列表开始,最简单的未实现的测试.
>写测试,还没有实现代码.
编写类的接口,使代码编译.
>运行测试,导致一次失败的测试.
写出测试通过的实现.
改变我所做的混乱
>转到2.
我的问题是编写实现或进行重构时.我经常得出结论,我刚才写的实现应该被委派给另一个类.
在这一点上,真正的TDD应该怎么做?
>将现有的测试列表单独留下一段时间,并为新发现的类创建一个新的测试列表(同样的问题可以在实现新的课程时显示出来)
>以互动方式进行测试,并将新类模拟,继续执行您正在处理的类的测试用例,稍后再来创建一个正确的嘲笑类的实现.
>这种情况不应该出现.我可能没有想好我的初步设计. (但不会失败TDD的目的之一!).
我很想知道别人如何处理这些情况.
我补充说,TDD的主要成就是进入红 – 绿重构的节奏.当你感受到这种节奏的好处时,你已经开始“得到”了.这并不是说你会发现在所有情况下都是值得的,但直到你感觉到节奏你没有得到它的倡导者喜欢的那样.
通常(特别是在架构复杂的应用程序,如n层应用程序)一些前期设计.没有什么画在石头上,但足以给单位一个地方去.当然,架构可能会以敏捷的方法发展,但是如果架构有多个层面,则景观的一般概念需要在那里.
编辑:(回应评论).新课程是否应该自行测试?不必要.这取决于课堂是否发展自己的重要性.当您进行单元测试时,您正在测试一个功能.这不是一个集成测试,只因为有两个类.当两个单位开始互动时,它将成为一个集成测试.我通常认为的边界是,如果我必须在A组中设置与B组的交互的重要状态,特别是如果A类组呼叫B组,以及什么我对测试感兴趣的是B对A的反应,那么我正在看一个集成测试.
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。