在成熟的项目中引入testing驱动开发（TDD）是否可行？
- 假设我们已经意识到TDD的价值太晚了。 项目已经成熟，很多客户开始使用它。
- 说使用自动化testing主要是function/系统testing，并且有很多自动GUItesting。
- 假设我们有新的function请求和新的错误报告（！）。 所以很多发展仍然在继续。
- 请注意，已经有很多没有或很lessunit testing的业务对象。
- 他们之间太多的协作/关系，只能通过更高层次的function/系统testing来进行testing。 没有集成testing本身。
- 大型数据库有大量的表格，视图等等。只是为了实例化一个单一的业务对象，已经有很多的数据库往返。
我们现在怎么介绍TDD呢？
嘲笑似乎是要走的路。 但是我们在这里需要做的嘲弄的数量似乎太多了。 听起来像精心devise的基础设施需要为现有的工具（BO，数据库等）工作的嘲笑系统开发。
这是否意味着只有从头开始时，TDD才是一种合适的方法？ 我有兴趣了解在已经成熟的产品中引入TDD的可行策略。
创build一个复杂的模拟基础结构可能会隐藏你的代码中的问题。 我build议你从集成testing和testing数据库开始，围绕你打算改变的代码库的各个方面。 一旦你有足够的testing，以确保你不会破坏任何东西，你可以开始重构代码，使其更易于testing。
另外，Michael Feathers出色的书籍与传统代码一起工作 ，对于任何想将TDD引入传统代码库的人来说，都必须阅读。
我认为把TDD引入到现有的应用中是完全可行的，事实上我最近自己做了。
以TDD方式编写新function和重构现有代码以适应这种情况是最容易的。 通过这种方式，您可以开始testing一小段代码，但效果开始在整个代码库中传播。
如果你有一个bug，那么编写一个unit testing来重现它，根据需要重构代码（除非这个努力真的不值得）。
就我个人而言，我不认为有必要疯狂地尝试和改造现有系统的testing，因为这可能是非常乏味而没有大量的好处。
总之，从小处着手，你的项目会越来越受到感染。
是的你可以。 从你的描述来看，这个项目是一个很好的forms – functiontesting自动化是一个很好的方法！ 在某些方面，它比unit testing更有用。 请记住，TDD！=unit testing，都是关于简短的迭代和可靠的验收标准。
请记住，拥有一个现有的和被接受的项目实际上使得testing更容易 – 工作应用程序是最好的需求规格。 所以，你比一个只有纸片的人要好一些。
刚开始使用TDD开始处理新的需求/错误修复。 请记住，切换方法会带来一些开销（请确保你的客户知道这一点！），并且可能会期望习惯了“古老的方式”的团队成员的不情愿。
除非需要，否则不要碰旧的东西。 如果你有一个会影响现有资料的增强请求，那么请花费额外的时间来做额外的设置。
就我个人而言，在引入复杂的模型基础设施方面我看不出太多的价值 – 当然，有一种方法可以在轻量级模式下实现相同的结果，但显然取决于您的情况
一个工具，可以帮助你testing遗留代码（假设你不能\没有时间重构它，Typemock Isolator：Typemock.com它允许注入依赖到现有的代码，而无需提取接口等，因为它不是使用标准的reflection技术（dynamic代理等），而是使用profiler API，它被用来testing依赖于共享点，HTTPContext和其他有问题的应用程序，我build议你看一看。该公司，但它是唯一的工具，不强迫你重构现有的遗留代码，节省您的时间和金钱），我也强烈build议“有效地使用遗留代码”更多的技术。
罗伊
是的你可以。 不要一下子把所有的东西都做完，而是只要介绍一下你需要testing的模块。
您也可以从更高水平的验收testing开始，然后从这里开始工作（请参阅Fitnesse ）。
我将从一些基本的集成testing开始。 这将会得到其他员工的支持。 然后开始分离你的代码中有依赖的部分。 努力使用dependency injection，因为它会使你的代码更加可testing。 将错误视为编写可testing代码的机会。
