我在一家大公司工作，但仅用两个人的团队来开发桌面LOB应用程序。我已经研究TDD已有很长时间了，尽管很容易实现其在大型应用程序中的好处，但我很难尝试证明在我们的应用程序规模上开始使用TDD的时间。
我了解它在自动化测试，提高可维护性等方面的优势，但就我们的规模而言，即使为我们所有组件编写基本的单元测试也很容易使开发时间加倍。由于我们已经没有足够的时间来完成最后的任务，所以我不确定该朝哪个方向前进。从那时起，敏捷迭代开发之类的其他实践就完美了，但我对小型团队中TDD的生产率权衡感到有些沮丧。
TDD的优势是否值得在时间表非常紧凑的小型团队上花费额外的开发时间？
Answers:
丑陋的事实是，一开始它会使您减速。任何新的过程或做法都需要花费一些时间才能逐步完善。以我的经验，TDD在初始实施方面的投入不如维护，错误修复和扩展那样。我知道对其他人来说，这是即时支出，所以这取决于每个人当前的编码风格。
尽管我是TDD的大力拥护者（我将其带入当前的工作中），但我认为您需要有一点喘息的空间（期限/时间表），以便探索和理解这种做法。
您的团队越小，您越能立即受益于TDD。我已经看到了从6到3的团队规模的支出。
您在谈论的额外开发时间可能只是一种幻想。
TDD与标准单元测试的不同之处在于，它不仅用于进行测试。
TDD is a new way of developing software。这是我所知道的最好方法之一。
因此，它与项目的大小无关。您将从第一行代码中提取好处。
在TDD上有一本很棒的书，《单元测试的艺术》（官方网站），其中有.net中的示例，并带有Java版本。好的方面是，整章都在考虑诸如“将单元测试集成到组织中”-第8章和“使用遗留代码”-第9章之类的问题。尽管我不是该领域的专家（但:-)） ，根据我的经验，我相信这是一个很好的起点。
当人们与我谈论开始在团队中采用测试时，我总是首先检查测试将如何运行。团队通常没有连续的构建。如果您的资源有限，那么我建议您设置CI服务器是开始认真尝试测试的先决条件。
完成设置后，就可以开始练习TDD。请记住，如果开发该系统时没有考虑到测试，那么您可能很难使现有代码可测试，并且对其进行重组将非常昂贵。
首先寻找容易开始使用TDD的地方-新的类或模块，几乎没有依赖关系。实用程序类和数据结构通常是很好的开始。
感受一下它如何改变您对代码的看法，注意所生成的代码有多好，以及您对该代码有多自信。
我知道我还没有真正回答这个问题，但是我想我的意思是，您应该能够在不花费大量额外费用的情况下完成所有这些工作。通过阅读第一个示例，您将更好地了解项目的优势。
底线-开发速度较慢，但缺陷很少，因此修复错误的时间更少。
在这里，我认为行为驱动开发会立即获得收益，但是我不确定测试驱动开发是否会取得收益。
在行为驱动的开发中，您以不同的方式处理问题：与业务人员坐下并与他们一起定义该功能块应具有的行为。我在博客的一个条目中对此进行了描述（帖子标题：Writing Behaviors）。
与业务人员或任何人坐下来，将帮助您和他们更好地了解系统需要做什么，以使每个人都满意该功能。它需要做什么才能被您已有的质量检查流程所接受。
定义测试标准，然后将这些测试标准写入自动测试套件中，应减少来回的次数：有人声称该功能已损坏，因为您错过了某些东西（要么是因为您合理地错过了一些东西，要么是因为他们从未告诉过您）关于此事）。
这也可能有助于其他人对您的团队的看法：如果您坐下来确定系统中需要完成的工作，则可以从“笨拙的白痴，这些白痴对一切进行过度的设计，并花时间在我们不要求的事情上”， “具有实用功能的聪明人”。
TL; DR：行为驱动开发可能会很快显示出改进，因为它以“客户”为重点。对我来说，“测试驱动开发”似乎是关于测试“没人”关心的代码库内部，并带来不太明显的业务收益。（行为驱动开发面临着立即的变化：工程师突然变得与“客户”或业务分析师有更多的面对面时间，以试图解决这个问题，这应该是一件好事。 ，他们正在召开有关Feature X的会议，这意味着该方面正在取得进展！”）