我们如何在这个阶段引入 TDD？
嘲笑似乎是要走的路。但是我们在这里需要做的嘲笑似乎太多了。听起来需要为适用于现有东西（BO、数据库等）的模拟系统开发复杂的基础设施。
这是否意味着只有从头开始时 TDD 才是合适的方法？我很想知道在已经成熟的产品中引入 TDD 的可行策略。
创建一个复杂的模拟基础设施可能只会隐藏代码中的问题。我建议您从集成测试开始，使用测试数据库，围绕您计划更改的代码库区域。一旦您有足够的测试以确保您在进行更改时不会破坏任何东西，您就可以开始重构代码以使其更具可测试性。
Se 也是 Michael Feathers 的优秀著作《有效地使用遗留代码》，对于任何想将 TDD 引入遗留代码库的人来说，这是一本必读的书。
我认为将 TDD 引入现有应用程序是完全可行的，事实上我最近自己做了。
以 TDD 方式编写新功能并重组现有代码以适应这种情况是最容易的。这样，您从测试代码的一小部分开始，但效果开始蔓延到整个代码库。
如果您有错误，请编写一个单元测试来重现它，并根据需要重构代码（除非付出的努力真的不值得）。
就个人而言，我认为没有必要发疯并尝试将测试改型到现有系统中，因为这可能非常乏味而没有很多好处。
总之，从小处着手，您的项目将变得越来越受测试感染。
是的你可以。根据您的描述，该项目处于良好状态 - 大量的功能测试自动化是一种方法！在某些方面，它甚至比单元测试更有用。请记住，TDD ！= 单元测试，这都是关于短迭代和可靠的验收标准。
请记住，拥有一个现有且被接受的项目实际上使测试更容易 - 工作应用程序是最好的需求规范。因此，与只有一张纸可以合作的人相比，您处于更好的位置。
只需开始使用 TDD 处理您的新需求/错误修复。请记住，切换方法会产生相关开销（确保您的客户意识到这一点！）并且可能期望习惯于“好的旧方法”的团队成员非常不情愿。
除非需要，否则不要碰旧的东西。如果您有一个会影响现有内容的增强请求，那么请考虑额外的时间来进行额外的设置。
就我个人而言，我认为为模型引入复杂的基础设施没有太大价值——当然有一种方法可以在轻量级模式下实现相同的结果，但这显然取决于你的情况
一种可以帮助您测试遗留代码的工具（假设您没有时间重构它，Typemock Isolator：Typemock.com 它允许将依赖项注入现有代码而无需提取接口等，因为它确实不使用标准反射技术（动态代理等），而是使用分析器 API。它已被用于测试依赖于共享点、HTTPContext 和其他问题区域的应用程序。我建议你看看。（我在该公司，但它是唯一不强迫您重构现有遗留代码的工具，从而节省您的时间和金钱）我还强烈建议“有效地使用遗留代码”以获得更多技术。
罗伊
是的你可以。不要一下子全部做完，而是在你接触到模块时只介绍你需要什么来测试它。
您还可以从更高级别的验收测试开始，然后从那里开始（查看Fitnesse的相关内容）。
我将从一些基本的集成测试开始。这将得到其他员工的支持。然后开始分离代码中具有依赖关系的部分。努力使用依赖注入，因为它会让你的代码更容易测试。将错误视为编写可测试代码的机会。