TDD：单元测试重点答案

【问题标题】：TDD: Unit testing focusTDD：单元测试重点
【发布时间】：2010-02-06 20:50:53
【问题描述】：

TDD 是否可以面向不同于单元测试的另一种测试？

【问题讨论】：

标签： unit-testing testing tdd

【解决方案1】：

虽然在对 TDD 的某些解释下这可能是可能的，但我认为 TDD 的要点是在任何生产代码之前编写测试。鉴于此，您不会拥有大型系统来为其编写集成或功能测试，因此测试必须在单元级别进行。

【讨论】：

这是一个很好的观点... :) 无论如何我们可以使用功能测试来开发软件吗？我想我们可以，你怎么看？
嗯，是的，我认为“提升一个档次”并仅测试功能需求没有任何主要问题。您最终可能会遇到对系统进行同样良好测试的困难。例如，一个由两个单元组成的系统，每个单元需要四个单元测试，可能需要十六个功能测试来达到相同的覆盖水平。增加组件的数量，确保覆盖所有案例所需的功能级别测试将爆炸式增长。我想我的意思是，如果您想要 TDD 建议的出色测试覆盖率，您可能需要单元测试。
同意冷静，这最终可以将我们引向与单元测试密切相关的 TDD，以提高效率。非常感谢：）
在开发人员编写代码的同时，我编写测试用例作为对规范的解释。如果我在他们完成代码之前完成了测试文档，我会给他们文档来试用。这与 TDD 的效果相同；在 QA 之前发现并修复了大量错误。我们甚至发现了对规范的误解，并为自己节省了一些代价高昂的后期重写。这是并行完成的，而不是先进行测试，但根据我的经验，我会说，是的，可以将一种 TDD 形式与其他类型的测试一起使用。
我从来没有听说过可信的“TDD 解释”，它说单元测试是唯一要编写的测试类型。有链接吗？

【解决方案2】：

Behavior-Driven Development (BDD) 在集成测试和功能测试层面应用了 TDD 的思想。

【讨论】：

谢谢，我完全不知道这种发展：)
我以前也是这么想的。现在我不这么想了 :P 你从哪里得到这个想法的？

【解决方案3】：

TDD 的红绿重构周期应该很快，真的很快。快速反馈让您保持最佳状态。我见过的 TDD 方法需要完整的故事，将其表达为测试，然后推动开发以通过该（大型）测试。它名义上是 TDD（或者可能是 BDD），但对我来说感觉不对。微小的步骤，单元测试，是我学习 TDD 的方式，我是如何思考它的，以及它是如何最适合我的。

【讨论】：

感谢卡尔的回答。是的，根据经验，单元测试可以更好地工作。 BDD 可能是个胖子：P 再次感谢。标清

【解决方案4】：

从技术上讲，TDD 是一种做事方式，而不仅仅是单元测试，理论上它应该驱动所有的开发过程。

理论上，测试驱动开发，对于更复杂的场景，例如系统之间的集成，您应该定义集成测试，然后编写代码以通过这些集成测试（即使测试不是自动化的）...

【讨论】：

【解决方案5】：

当然可以。 TDD 依赖于自动化测试，这与测试的“类型”正交。

【讨论】：

【解决方案6】：

如果您专注于想法，而不是技术实现，那就可以了。我的意思是，如果你暂时忘记了单元测试，并专注于首先编写测试的想法，然后再编写实现，以实现比它更清晰的设计在系统层面。

想象一下，你有一些要求。基于此，您编写用户验收测试测试 - 捕获功能的高级测试。接下来您开始开发 - 您已经有了 UAT 测试形式的用例。您确切地知道预期的内容，因此更容易实现所需的功能。

其他示例是基于 scrum 的项目。在计划会议中，您讨论/创建/拥有稍后在 sprint 期间开发的用户故事。这些用户故事实际上可以是 UAT 测试。

无论如何，我认为 TDD 是预先指定设计的方式，而不是应用程序测试周期/阶段/方法。 TDD 被视为单元测试同义词的原因是单元测试尽可能接近开发人员。对于开发人员来说，它们似乎是表达类/方法的功能设计的自然方式。

【讨论】：

【解决方案7】：

当然！ TDD 根本不需要单元测试。不幸的是，这似乎是一个常见的误解。

举一个具体的例子，我完全通过集成测试来推动我的开源模拟库（用于Java）的开发。我不会为内部类编写单独的单元测试。相反，对于每个新功能或增强功能，我首先添加一个失败的验收（集成）测试，然后更改或添加到现有的生产代码，直到测试通过。通过最终的重构步骤，这就是纯粹的 TDD，即使没有编写 unit 测试。

【讨论】：