Testing 在执行TDD时发现其他对象
我正在努力练习TDD 我的理解是，TDD应该是这样的Testing 在执行TDD时发现其他对象,testing,tdd,Testing,Tdd,我正在努力练习TDD 我的理解是，TDD应该是这样的 为我将要开发的接口/类编写一个测试列表 从我的测试列表中最简单的未实现测试开始 编写测试，还没有实现代码 编写类的接口以使代码可编译 运行测试，导致一个测试失败 编写使测试通过的实现 把我弄得一团糟 转到2 我遇到的问题是在编写实现或进行重构时。我经常得出这样的结论：我刚刚编写的实现应该委托给另一个类 在这一点上，真正的TDD'r应该做什么 暂时不要使用现有的测试列表，为新发现的类创建一个新的测试列表（在实现新类时，同样的问题也会表现出来）
我很想知道其他人是如何处理这些情况的。不要在测试和类之间寻找一对一的关系。如果您决定引入一个新类，那么就让它成为原始测试支持的重构，并在您想要添加功能（或测试您需要涵盖的尚未测试的可能情况）时，在适当的位置（这取决于具体情况）添加测试 我想补充一点，TDD的主要成功在于融入红-绿重构的节奏。当你感受到这种节奏的好处时，你就开始“理解”它。这并不是说你会发现它在所有情况下都是值得的，但在你感受到这种节奏之前，你还没有达到它的拥护者喜欢的程度 而且通常（特别是在架构复杂的应用程序中，如n层应用程序）有一些预先设计。没有什么是用石头画的，但足够给单位一个地方去。当然，架构可能会在敏捷方法中发展，但如果架构有多个层次，则需要有一个总体的景观概念
编辑：（回应评论）。新类是否应该自行测试？不一定。这取决于班级是否发展出自己的重要性。当您进行单元测试时，您正在测试一项功能。它不是一个集成测试，因为它涉及两个类。当两个单元开始交互时，它成为一个集成测试。我通常想到的边界是，如果我必须在类A组中设置重要状态以与类B组交互，特别是如果类A组调用类B组，我感兴趣的是测试B组对A的反应，那么我正在考虑集成测试。您应该创建一个模拟类。具有可预测结果的单一接口。所以你可以测试原版
稍后，您可以对新类重复此过程。当我遇到这种情况时，我会遵循您的解决方案#1。继续递归，创建尽可能多的您认为合适的类，直到您有了满意的实现集合。有了经验，你会发现你的设计反映了你的经验，而这种事情不会发生太多 我的问题是当我 到达第6点和第7点，在某个点 随着时间的推移，我总是来参加聚会 结论：实施I 刚才写的应该委托给 另一节课 使用不同的类来实现您的设计会更好——这就是设计，这就是TDD的要点。所以这是件好事，不应该打扰你
但这让你很烦恼。那怎么办呢？认识到委托给另一个类是一种重构；这是在第6步之后、第7步期间要做的事情。一旦你是绿色的，重构到一个更好的设计。你已经有了新类的测试；他们只是打电话给原来的班级。那很好。在提取类并进行委派之后，如果您更愿意让测试直接调用提取的类，那么：开始吧。没有害处。如果提取的类开始被其他调用方使用，我会推荐它，也许当您开始从其他类调用它时，是这样做的好时机（但如果它让您感到不适，现在就做）。这正是我现在正在做的，但我不喜欢它分散您对正在测试的类的注意力。过了一段时间，你回到那门课上，试着找出你离开的地方。正如伊赛所说，你不应该从测试课程的角度来思考。您正在测试问题解决方案的实现，如果实现碰巧跨多个类，这很好。但是新类应该自己测试，不是吗？如果设计让你喜欢创建多个“支持”类，那么你开始的单元测试将成为一个集成测试。事实上，这是我认为我应该做的，但在那里，有一场关于“基于状态”和“基于交互的测试”的圣战正在进行。我不喜欢这个解决方案将您的测试与您使用的接口的特定声明联系在一起。在基于状态的测试中，我可以更改支持类的接口声明（很可能），而无需更改我的测试用例。使用基于交互的测试，我还必须更改测试用例。