我正在努力练习TDD.
我的理解是TDD应该这样
>编写我将要开发的接口/类的测试列表.
>从我的测试列表开始,最简单的未实现的测试.
>写测试,还没有实现代码.
编写类的接口,使代码编译.
>运行测试,导致一次失败的测试.
写出测试通过的实现.
改变我所做的混乱
>转到2.
我的问题是编写实现或进行重构时.我经常得出结论,我刚才写的实现应该被委派给另一个类.
在这一点上,真正的TDD应该怎么做？
>将现有的测试列表单独留下一段时间,并为新发现的类创建一个新的测试列表(同样的问题可以在实现新的课程时显示出来)
>以互动方式进行测试,并将新类模拟,继续执行您正在处理的类的测试用例,稍后再来创建一个正确的嘲笑类的实现.
>这种情况不应该出现.我可能没有想好我的初步设计. (但不会失败TDD的目的之一！).
我很想知道别人如何处理这些情况.
不要在你的测试和你的班级之间寻找一对一的关系.如果您决定引入一个新类,那么这是一个原始测试支持的重构,并且当您要添加功能(或测试您需要的可能性)时,在适当的位置添加测试(在哪些方面取决于具体情况)覆盖你还没有测试)
原文链接：https://www.f2er.com/javaschema/281446.html我补充说,TDD的主要成就是进入红 – 绿重构的节奏.当你感受到这种节奏的好处时,你已经开始“得到”了.这并不是说你会发现在所有情况下都是值得的,但直到你感觉到节奏你没有得到它的倡导者喜欢的那样.
通常(特别是在架构复杂的应用程序,如n层应用程序)一些前期设计.没有什么画在石头上,但足以给单位一个地方去.当然,架构可能会以敏捷的方法发展,但是如果架构有多个层面,则景观的一般概念需要在那里.
编辑：(回应评论).新课程是否应该自行测试？不必要.这取决于课堂是否发展自己的重要性.当您进行单元测试时,您正在测试一个功能.这不是一个集成测试,只因为有两个类.当两个单位开始互动时,它将成为一个集成测试.我通常认为的边界是,如果我必须在A组中设置与B组的交互的重要状态,特别是如果A类组呼叫B组,以及什么我对测试感兴趣的是B对A的反应,那么我正在看一个集成测试.
