在成熟的项目中引入测试驱动开发(TDD)是否可行？

Question

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

我们怎样才能在这个阶段引入TDD？

嘲弄似乎是要走的路.但是我们在这里需要做的嘲弄似乎太多了.听起来需要为现有的东西(BO,数据库等)工作的模拟系统开发精心设计的基础设施.

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

Answer 1

创建复杂的模拟基础架构可能只是隐藏代码中的问题.我建议您从集成测试开始,使用测试数据库,围绕您计划更改的代码库区域.一旦你有足够的测试来确保你做出改变就不会破坏任何东西,你可以开始重构代码以使其更易于测试.

Se还有Michael Feathers优秀的书籍,有效地使用遗留代码,对于任何想要将TDD引入遗留代码库的人来说,它都是必读的.

Answer 2

我认为将TDD引入现有应用程序是完全可行的,事实上我最近自己做了.

最简单的方法是以TDD方式编写新功能,并重构现有代码以适应这种情况.这样你开始测试代码的一小部分,但效果开始在整个代码库中传播.

如果你有一个bug,那就写一个单元测试来重现它,根据需要重构代码(除非努力真的不值得).

就我个人而言,我认为没有必要发疯,并尝试将测试改装到现有系统中,因为如果没有大量的好处,这可能会非常繁琐.

总之,从小开始,您的项目将变得越来越多的测试感染.

Answer 3

是的你可以.根据您的描述,该项目处于良好状态 - 大量的功能测试自动化是一种方法!在某些方面,它比单元测试更有用.请记住,TDD!=单元测试,它都是关于短迭代和可靠的验收标准.

请记住,拥有一个现有的和接受的项目实际上使测试更容易 - 工作应用程序是最好的需求规范.因此,与那些只需要一张废纸的人相比,你处于一个更好的位置.

刚开始使用TDD处理新的需求/错误修复.请记住,切换方法会产生相关的开销(确保您的客户意识到这一点!)并且可能期望那些习惯于"老方法"的团队成员不愿意这么做.

除非你需要,否则不要碰旧的东西.如果您有一个会影响现有内容的增强请求,那么请考虑额外的时间来进行额外的设置.

就个人而言,我没有看到为模型引入复杂的基础设施有多大价值 - 当然有一种方法可以在轻量级模式下实现相同的结果但显然取决于您的具体情况

Answer 4

一个可以帮助你测试遗留代码的工具(假设你不能没有时间重构它)是Typemock Isolator:Typemock.com它允许将依赖注入现有代码而不需要提取接口等因为它确实如此不使用标准反射技术(动态代理等),而是使用探查器API.它用于测试依赖于sharepoint,HTTPContext和其他问题区域的应用程序.我建议你看看.(我作为开发人员工作)该公司,但它是唯一不会强制您重构现有遗留代码的工具,节省您的时间和金钱)我还强烈建议"有效地使用遗留代码"以获得更多技术.

罗伊