在成熟的项目中引入测试驱动开发(TDD)是否可行? [英] Is it feasible to introduce Test Driven Development (TDD) in a mature project?

问题描述

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

我们现阶段如何引入TDD?

How can we introduce TDD at this stage?

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

Mocking seems to be the way to go. But the amount of mocking we need to do here seems like too much. Sounds like elaborate infrastructure needs to be developed for the mocking system working for existing stuff (BO, databases, etc.).

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

Does that mean TDD is a suitable methodology only when starting from scratch? I am interested to hear about the feasible strategies to introduce TDD in an already mature product.

推荐答案

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

Creating a complex mocking infrastructure will probably just hide the problems in your code. I would recommend that you start with integration tests, with a test database, around the areas of the code base that you plan to change. Once you have enough tests to ensure that you won't break anything if you make a change, you can start to refactor the code to make it more testable.

迈克尔·费瑟斯(Michael Feathers)的优秀著作有效地处理旧版代码，对于任何想将TDD引入遗留代码库的人来说都是必读的内容.

Se also Michael Feathers excellent book Working effectively with legacy code, its a must read for anyone thinking of introducing TDD into a legacy code base.

这篇关于在成熟的项目中引入测试驱动开发(TDD)是否可行?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！