加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 百科 > 正文

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

发布时间:2020-12-14 01:07:36 所属栏目:百科 来源:网络整理
导读:说我们已经意识到TDD的价值太晚了。项目已经成熟,很多客户开始使用它。 说使用的自动测试主要是功能/系统测试,并有大量的自动GUI测试。 说我们有新的功能请求和新的错误报告(!)。所以很多发展仍在继续。 注意,已经有很多业务对象没有或很少的单元测试。
>说我们已经意识到TDD的价值太晚了。项目已经成熟,很多客户开始使用它。
>说使用的自动测试主要是功能/系统测试,并有大量的自动GUI测试。
>说我们有新的功能请求和新的错误报告(!)。所以很多发展仍在继续。
>注意,已经有很多业务对象没有或很少的单元测试。
>它们之间的协作/关系太多,只有通过更高级别的功能/系统测试才能测试。没有集成测试本身。
>大数据库到位有大量的表,视图等。只是为了实例化单个业务对象,已经有很多数据库往返。

我们如何在这个阶段引入TDD?

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

这是否意味着TDD只是从零开始是一个合适的方法?我有兴趣了解在已经成熟的产品中引入TDD的可行策略。

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

还有迈克尔·费舍斯的优秀书Working effectively with legacy code,它必须阅读为任何人想引入TDD到遗留的代码基础。

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读