许多开发人员正在使用Test Driven Development（TDD）设计他们的应用程序，但我想知道我应该在哪个阶段将TDD合并到我的项目中？我应该首先设计我的类，进行一些单元测试并确定需要哪些方法或首先设计方法，然后再进行一些单元测试？
最好的方法是什么？
答案 0 :(得分：18)
测试驱动的关键是测试驱动设计和实现。
在某些情况下这是不合适的 - 设计看起来应该是显而易见的，特别是如果它实现了现有的界面（或一些类似的限制选择），但是当你有一个大的“设计空间”时，TDD鼓励你可以编写测试来证明你希望如何使用这个课程，而不是从你开始想象你想要实现它。
一般来说，如果某些东西很容易测试，它就会很容易使用。
答案 1 :(得分：18)
您所做的线框将为您提供系统应如何显示的想法。大规模设计将让您了解要创建的类。但是，这些模型都不应被视为正确或永久。在编写测试时，您会找到更好的设计思路，这些思路将改变您的高级设计，甚至是您的线框设计。
答案 2 :(得分：6)
测试驱动设计的口号：
对每个项目重复。
答案 3 :(得分：2)
我对在实施之前编写单元测试持怀疑态度。如果您对所需的类和方法的确切设计有一个很好的了解，但通常在新项目的开始时，您可能不会有效。
我首选的方法是承认新项目的开始可能会有点混乱。设计过程的一部分是编写代码来验证某些想法或找到最佳方法。很多时候代码都会遇到死胡同而被抛弃，任何针对它编写的单元测试都会浪费时间。
不要误会我的意思我都是设计精良的软件，在某些时候，有组织的混乱变成了一个很好理解的设计是至关重要的。此时，类结构和UML图开始凝固。这是TDD对我来说很重要的一点。每个班级都应该能够孤立地进行测试。如果设计良好，适当的解耦程度通常可以通过在地方周围喷洒模拟物体来轻松实现。如果设计不好，那么测试就会成为一场真正的噩梦，因而被忽略了。
在一天结束时，它是您追求的高质量生产代码。单元测试是帮助实现这一目标的最佳工具之一，但它们不应该过自己的生活，并且比他们测试的代码更重要，你有时会从TDD口头禅中感受到它。
答案 4 :(得分：2)
从小处开始
a）下次将一个方法添加到Utility类时，首先为该方法编写测试。进行字符串处理的方法是一个很好的起点，因为它们往往有很多错误，但是不需要复杂的数据集来测试它们。
b）然后，一旦您获得了编写单元测试的知己，请移动不接触UI的类，不要直接或间接地与数据库对话。
c）然后您必须决定是否设计应用程序以使单元测试更容易。 E.g
a）和b）有一个很大的回报，而不必改变你设计整个系统的方式。您必须考虑c）是否值得花费....（我认为是，但很多人不这样做，而且经常无法控制整个系统设计。）
答案 5 :(得分：1)
理想情况下，您将在开始编码时开始应用TDD。 首先考虑关于您的设计，您可以在纸上绘制图表;无需使用CASE工具，只需设想主要类及其交互，选择一个，编写第一个简单测试，编写代码使其通过，编写另一个测试，使其通过，重构......
如果您的流程要求在编码阶段之前记录和审查设计，那么您就无法遵循TDD并让您的设计出现。但是，您可以先进行设计，然后再进行实施测试。您将获得单元测试，就像您应用了TDD一样，但仍在应用您的过程。
尽可能保持您的设计高级别，以便您可以让设计的低级细节出现。
答案 6 :(得分：0)
答案 7 :(得分：0)
TDD确保开发人员与业务逻辑相比，对测试用例同等重要。我在我的项目中跟着它，我可以看到它的优点：自从我开始编写我的测试用例之后，我确保我的测试用例处理业务逻辑的所有可能的覆盖范围，从而捕获/减少错误的数量。有时它不实用，因为它需要足够的时间来编写这些测试用例。 最重要的是你需要对代码进行单元测试。所以你要先从实现开始，然后确保所有场景都有足够的测试用例（大多数人都没有因此这种做法已经出现。）或者编写测试方法呢干运行然后编写您的实现。只有当所有测试用例成功通过后，您的实现才会完成。
答案 8 :(得分：0)
你应该听一下他们谈论TTD的堆栈溢出播客41。很难说每个人都在使用TDD，并且需要花费大量的时间和资源来获得高代码覆盖百分比。如果为所有代码编写测试，单元测试可以有效地缩短开发时间。
播客中的一点是，您可以更好地利用时间和资源完成其他任务，例如可用性和新功能。