我们公司正在改进代码质量和交付代码时采用的流程。我的问题与单元测试有关，我想收集有关当您被要求实现功能时所采用的流程的信息。
TDD 是单元测试的一种形式吗？根据我在 TDD 中的理解，您首先编写测试（失败），编写代码，然后运行应该通过的测试。可能是代码会进行外部方法调用。但是，当我们首先编写测试时，我们应该如何知道所需的存根呢？
当您构建您的应用程序之前的版本时，您在构建中包含哪些类型的测试？构建运行您的集成测试还是只运行您的单元测试？
除了 TDD，你还写过其他类型的测试吗？抱歉，如果问题略有失真。非常感谢您在如何进行开发方面的经验。谢谢
TDD 远不止单元测试——所以我想说单元测试只是 TDD 的一部分。我认为整个方法论可以包括对软件开发中任何过程的结果创建测试（表达对正确行为的期望/要求）。无论是编写代码、构建脚本、部署脚本、数据库脚本、数据导入/导出/转换……无论您需要做什么，您都应该问自己：“我如何证明这有效？我可以为此自动化测试吗？ "
举个例子：一些经常被忽视的东西，因为它超出了单元测试的范围，但它是一个非常有效的测试，并且在开发过程中对前端加载很重要的是部署。
如果一个软件开发不能轻易地部署到生产环境而不需要大量的努力和改变（对软件或环境架构），那么提前知道这一点很重要，而不是在它必须上线前一周。一旦你确定了这个过程，有一种测试方法来确保它被正确部署不是很好吗？
当您了解该过程时 - 为什么不编写脚本并使其自动化？如果您知道要求是必须部署它，为什么不在部署之前为此编写一个测试呢？
我之前已经说过，但我会再说一遍——我在这个主题上找到的最好的资源是Growing Object-Oriented Software, Guided by Tests——它是Kent Beck 签名系列的一部分。
TDD 与测试无关。TDD使用测试来驱动代码的设计。TDD产生测试是通过首先编写测试来设计代码的一个愉快的副作用，但它与测试无关：它不是一种测试方法，目的也不是产生测试。
测试驱动开发是单元测试的一种形式吗？
不，这是一种设计方法。
根据我对 TDD 的理解，您首先编写测试（失败），编写代码，然后运行应该通过的测试。
你错过了一个非常重要的步骤。你先写你的测试，你写你的代码，直到你的测试通过——然后你重构. 测试允许您安全地重构，确保在您调整设计时所需的行为继续有效。这些测试还引导您使用可测试的代码，促进更小的方法、更短的参数列表以及比其他方法引导您更简单的整体设计。
除了 TDD，你还写过其他类型的测试吗？
当我这样做时，通常表明我未能正确执行 TDD（但它肯定会发生）。我们有单元测试和用户验收测试；两者都可以在代码之前编写，但有时我们的用户验收测试是在开发周期的后期编写的。他们不应该是，但有时他们是。
TDD 是关于在最初的 Red-Green-Refactor 循环的 5 分钟左右内进行设计。但这可以说是永远的测试，因为没有什么可设计的了——您的 TDD 测试然后成为完美测试工具的一部分，以检测由进一步发展引起的回归。所以是的，我想你可以说测试驱动开发是单元测试的一种形式:)
但是，当我们首先编写测试时，我们应该如何知道所需的存根呢？
TDD 通常需要（快速）事先建模会话，您可以在其中充实 SUT 将与之协作的大图类。
但是，您无需详细了解这些合作者的工作方式。对于模拟，您基本上会一厢情愿地认为，当您稍后对它们进行 TDD 时，它们的实现会正确运行，因此现在您可以只专注于 SUT。
当您构建您的应用程序之前的版本时，您在构建中包含哪些类型的测试？构建运行您的集成测试还是只运行您的单元测试？
当您练习持续集成时，您的单元测试应该每次都运行，因此理论上您可以采用任何（非失败）构建并将其用作发布构建。
但是，您可能还想在发布版本之前运行自动化或手动集成/验收测试。例如，GUI 通常不容易进行单元测试，因此验收/集成测试是跟踪其中错误的好方法。
您在这里有几个问题，我会尝试按逻辑顺序解决它们
TDD 是单元测试的一种形式吗？
我说“是”，从某种意义上说，它创建了单元测试，即使它不是使用 TDD 的唯一好处。关于评论员强调但您的问题中未提及的主题：TDD 不仅确保测试覆盖率和文档化（良好的测试是低级代码文档的最佳形式之一）。使用 TDD 会迫使您做出某些设计决策，通常会改进整体应用程序设计。
你写其他测试吗？
好吧，我不写任何其他单元测试。TDD 的重点是代码的开发与测试的开发并行。通过在一个循环中编写软件 - 单个测试，只有足够的代码通过它，您可以确定您的测试记录了您从代码中需要的所有功能和行为，并且您确保代码是可测试的（您必须编写它那样做TDD）。不需要额外的单元测试
您应该使用其他类型的测试。首先想到的是集成测试，但还有其他的，比如验收测试。如果你有这些自动化，你会更容易。不是你应该编写验收测试——应该是你的客户/利益相关者，你应该在编写它们的技术部分帮助他。您可能对 Fitnesse http://fitnesse.org/感兴趣- 它是一个帮助非技术人员构建验收测试的工具。
关于打桩？
如果没有具体的例子，很难讨论这个问题。我现在只能说 - 一次只编写一个测试代码。如果你这样做了，你可能不会遇到这样的情况：你有一个复杂的类并考虑如何存根它的复杂依赖关系。
构建中应该包含哪些测试？
我说 - 如果可能的话，所有这些！