许多开发人员正在使用Test Driven Development (TDD) 设计他们的应用程序，但我想知道应该在哪个阶段将 TDD 合并到我的项目中？我应该先设计我的类，做一些单元测试并确定需要哪些方法，还是先设计方法，然后再做一些单元测试？
最好的方法是什么？
【问题讨论】：
标签： tdd
TDD 是一种编码和小型设计技术。这不是一种宏观的构想技术。如果你开始编写一个应用程序，你会想做一些故事板、线框图，甚至是一些简单的草图。您应该对更大规模的设计有所了解，即系统中的类和关系。在您开始进行交互设计（例如方法和参数）之前，您开始进行 TDD。
您所做的线框将为您提供系统应该如何显示的想法。大规模设计将使您了解要创建哪些类。然而，这些模型都不应该被认为是正确的或永久的。在编写测试时，您会发现更好的设计理念，这些理念将改变您的高级设计，甚至您的线框设计。
【讨论】：
测试驱动的意义在于驱动测试驱动设计和实现。
在某些情况下这是不合适的 - 设计应该是什么样子可能非常明显，特别是如果它正在实现现有接口（或一些类似的受限选择）但当你有一个很大的“设计空间”时，TDD 鼓励你要编写测试来展示你希望如何使用这个类，而不是从你认为你想如何实现它开始。
一般来说，如果某些东西容易测试，它就会很容易使用。
【讨论】：
测试驱动设计的口头禅：
对每个项目重复。
【讨论】：
我对在实现之前编写单元测试持怀疑态度。如果您对所需的类和方法的确切设计有一个很好的了解，但通常在新项目开始时您不了解，这可能会很有效。
我的首选方法是承认新项目的开始可能会有些混乱。设计过程的一部分是编写代码来验证某些想法或找到最佳方法。很多时候代码陷入死胡同并被丢弃，为它编写的任何单元测试都是浪费时间。
不要误会我的意思，我完全支持精心设计的软件，在某些时候，将有组织的混乱转变为易于理解的设计至关重要。那时，类结构和 UML 图开始固化。这就是 TDD 对我来说很重要的一点。每个班级都应该能够单独进行测试。如果设计是好的，具有适当程度的解耦，通常在该位置周围撒一些模拟对象很容易实现。如果设计不好，测试将成为一场真正的噩梦并因此被忽略。
归根结底，您需要的是高质量的高效代码。单元测试是帮助实现这一目标的最佳工具之一，但它们不应该独树一帜，并且变得比它们正在测试的代码更重要，您有时会从 TDD 的口头禅中感受到这种感觉。
【讨论】：
从小处着手
a) 下次向 Utility 类添加方法时，首先为该方法编写测试。进行字符串处理的方法是一个很好的起点，因为它们往往有很多错误，但不需要复杂的数据集来测试它们。
b) 然后，一旦您对编写单元测试有信心，请继续使用不涉及 UI 且不直接或间接与数据库对话的类。
c) 然后您必须决定是否设计您的应用程序以使单元测试更容易。例如
a) 和 b) 无需改变您设计整个系统的方式即可获得巨大回报。您必须考虑 c) 是否物有所值....（我认为是，但很多人不这样做，而且您通常无法控制整个系统设计。）
【讨论】：
理想情况下，您将在开始编码时开始应用 TDD。 想想先想好你的设计，你可以在纸上画图；无需使用 CASE 工具，只需设想主要类及其交互，选择一个，编写第一个简单测试，编写代码使其通过，编写另一个测试，使其通过，重构 ...
如果您的流程要求在编码阶段之前记录和审查设计，那么您就不能遵循 TDD 并让您的设计浮出水面。但是，您可以先进行设计，然后先进行实施测试。您将像应用 TDD 一样获得单元测试，但仍应用您的流程。
让你的设计尽可能的高层次，这样你就可以让设计的低层次细节浮出水面。
【讨论】：
【讨论】：
TDD 确保开发人员对测试用例的重视程度与其业务逻辑的重视程度相同。我在我的项目中遵循了它，我可以看到它的优点：因为我首先编写测试用例，所以我确保我的测试用例处理业务逻辑的所有可能覆盖范围，从而捕获/减少错误的数量。有时它不实用，因为它需要足够的时间来编写这些测试用例。 底线是你需要对你的代码进行很好的单元测试。所以要么从实现开始，然后确保所有场景都有足够的测试用例（大多数人没有因此出现这种做法。）要么编写测试方法试运行，然后编写您的实现。只有当您的所有测试用例都成功通过时，您的实现才算完成。
【讨论】：
您应该收听堆栈溢出播客 41，他们在其中谈论 TTD。很难说每个人都在使用 TDD，要获得高代码覆盖率需要大量时间和资源。如果您为所有代码编写测试，单元测试可以有效地使开发时间加倍。
播客中的一个要点是，您的时间和资源可以更好地用于其他任务，例如可用性和新功能。
【讨论】：