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