在成熟的项目中引入测试驱动开发（TDD）是否可行？
- 假设我们已经意识到TDD的价值太晚了。项目已经成熟，许多客户开始使用它。
- 说使用的自动化测试大多是功能/系统测试，并且有很多自动GUI测试。
- 假设我们有新的功能请求和新的错误报告（！）。所以很多发展仍在继续。
- 请注意，已经有很多没有或很少进行单元测试的业务对象。
- 它们之间的过多协作/关系，它们只能通过更高级别的功能/系统测试进行测试。没有集成测试本身。
- 有大量表格，视图等的大型数据库。为了实例化单个业务对象，已经进行了大量的数据库往返。
我们现在怎么介绍TDD？在成熟的项目中引入测试驱动开发（TDD）是否可行？
嘲笑似乎是要走的路。但是我们在这里需要做的嘲笑似乎太多了。听起来像需要为现有的工具（BO，数据库等）工作的嘲笑系统开发精心设计的基础架构。
这是否意味着只有从头开始时，TDD才是一种合适的方法？我有兴趣了解在已经成熟的产品中引入TDD的可行策略。
创建一个复杂的模拟基础设施可能会隐藏您的代码中的问题。我会建议您从集成测试开始，使用测试数据库，围绕您计划更改的代码库的各个方面。一旦你有足够的测试，以确保你不会破坏任何东西，如果你做出改变，你可以开始重构代码，使其更容易测试。
另外，Michael Feathers出色的书Working effectively with legacy code，对于任何想将TDD引入遗留代码库的人来说，它都是必读的。
我认为将TDD引入现有的应用程序是完全可行的，实际上我最近自己做了。
以TDD方式编写新功能并重构现有代码以适应此问题最为简单。通过这种方式，您可以开始测试一小段代码，但效果开始在整个代码库中传播。
如果你有一个bug，然后编写一个单元测试来重现它，必要时重构代码（除非这个努力真的不值得）。个人而言，我不认为有必要疯狂尝试将测试改装到现有系统中，因为这可能非常乏味而没有大量的好处。
总之，从小处开始，您的项目将变得越来越受到感染。
编写有关bug的新单元测试效果很好。你没有一个“完整的”测试套件，但你有一些东西可以建立。 – 2008-09-20 20:31:58
是的，你可以。从你的描述来看，这个项目处于良好的状态 - 功能测试自动化是一种可行的方法！在某些方面，它比单元测试更有用。请记住，TDD！=单元测试，这都是关于短迭代和可靠的验收标准。
请记住，拥有一个现有的和被接受的项目实际上使测试更容易 - 工作应用程序是最好的需求规格。所以，你比一个只有一纸废纸的人处在一个更好的位置。
刚开始使用TDD开始处理新的需求/错误修复。请记住，切换方法会产生开销（确保你的客户意识到这一点！），并且可能期望习惯于“古老的方式”的团队成员有很大的不情愿。
除非您需要，否则请勿触摸旧的东西。如果你有一个会影响现有资料的增强请求，那么请花费额外的时间来完成额外的设置。
个人而言，我没有看到多少价值的引入对实物模型，复杂的基础设施 - 肯定有一种方法可以实现一个轻量级的模式相同的结果，但它显然取决于您的具体情况
对于“TTD！=单元测试”+1，现在我将修复该错字。 – Johnsyweb 2011-06-07 12:28:43
我将开始进行一些基本的集成测试。这将得到其他员工的支持。然后开始分离具有依赖关系的代码部分。努力使用依赖注入，因为它会使您的代码更加可测试。将错误视为编写可测试代码的机会。
可以帮助您测试遗留代码的一种工具（假设您不能\没有时间重构它，是Typemock Isolator：Typemock.com 它允许在现有代码中注入依赖项而无需提取接口因为它不使用标准的反射技术（动态代理等），而是使用分析器API来代替。 它被用来测试依赖于Sharepoint，HTTPContext和其他有问题区域的应用程序 我建议你看看。 （我作为该公司的一名开发人员工作，但它是唯一一个不会强迫您重构现有遗留代码的工具，可以节省您的时间和金钱） 我还强烈建议“使用遗留代码进行有效工作”获取更多技术。
Roy
感谢您的建议。它看起来就是我所寻找的。 – rpattabi 2008-09-20 11:41:00