• 假设我们已经意识到TDD的价值为时已晚。项目已经成熟，大量客户开始使用它。
• 假设使用的自动化测试主要是功能/系统测试，并且有大量的自动化GUI测试。
• 假设我们有新功能请求和新错误报告(！)。因此，大量的开发工作仍在继续。
• 注意，已经有很多没有或者很少进行单元测试的业务对象。
• 它们之间的协作/关系过多，这只能通过更高级别的功能/系统测试来进行测试。本身没有集成测试。
• 具有大量表，视图等的大型数据库就位。仅仅为了实例化一个业务对象，已经进行了大量的数据库往返。

我们现阶段如何介绍TDD？

模拟似乎是要走的路。但是我们在这里需要做的模拟工作似乎太多了。听起来需要为适用于现有内容(BO，数据库等)的模拟系统开发复杂的基础架构。

这是否意味着TDD仅在从头开始时才是合适的方法？我很想知道在已经成熟的产品中引入TDD的可行策略。

解决方案

是的你可以。不要一次完成所有操作，而要介绍一下触摸模块时需要进行的测试。

我们还可以从更高级别的验收测试开始，然后逐步进行(为此查看Fitnessit)。

创建一个复杂的模拟基础架构可能只会在代码中隐藏问题。我建议我们从计划更改的代码库区域开始，从集成测试和测试数据库开始。一旦进行了足够的测试以确保进行更改不会破坏任何内容，就可以开始重构代码以使其更具可测试性。

Se也是Michael Feathers的优秀著作，有效地使用了遗留代码，对于任何想将TDD引入遗留代码库的人来说都是必读的。

我认为将TDD引入现有应用程序是完全可行的，实际上我最近亲自完成了它。

以TDD方式编码新功能并重组现有代码以适应此功能是最容易的。这样，我们可以从一小部分经过测试的代码开始，但是效果开始在整个代码库中扩散。

如果我们有错误，请编写一个单元测试来重现它，并在必要时重构代码(除非付出的努力确实不值得)。

就我个人而言，我认为没有必要发疯并尝试将测试改造到现有系统中，因为这可能非常繁琐而又没有很多好处。

总之，从小处着手，项目将越来越多地受到测试的感染。

是的你可以。根据描述，项目处于良好状态，大量的功能测试是自动化的方法！在某些方面，它比单元测试更有用。请记住，TDD！=单元测试，全部都是关于短迭代和可靠的接受标准。

请记住，拥有一个现有的并被接受的项目实际上会使测试工作应用程序更容易，这是最佳的需求规范。因此，位置要比只剩下几张纸的人处于更好的位置。

刚开始使用TDD处理新的需求/错误修复。请记住，切换方法会带来额外的开销(确保客户意识到这一点！)，并且可能希望习惯于"好的旧方法"的团队成员会很不情愿。

除非需要，否则不要触摸旧东西。如果我们有一个会影响现有内容的增强请求，请考虑将额外的时间用于进行额外的设置。

我个人认为为复杂的模型引入复杂的基础架构并没有太大的价值，但是肯定有一种方法可以在轻量级模式下实现相同的结果，但这显然取决于情况。

我将从一些基本的集成测试开始。这将得到其余员工的支持。然后开始分离代码中具有依赖性的部分。努力使用依赖注入，因为它将使代码更具可测试性。将错误视为编写可测试代码的机会。

Typemock隔离器是一种可以测试遗留代码的工具(假设我们无法\没有时间对其进行重构)，即Typemock隔离器：Typemock.com
它允许将依赖项注入到现有代码中，而无需提取接口等，因为它不使用标准的反射技术(动态代理等)，而是使用探查器API。
它已用于测试依赖于共享点，HTTPContext和其他问题区域的应用程序。
我建议你看看。
(我在那家公司担任开发人员，但这是唯一不强迫我们重构现有遗留代码，从而节省时间和金钱的工具)
对于更多技术，我也强烈建议"有效使用遗留代码"。

罗伊