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

单元测试 – TDD:为什么’Red Green Refactor’而不仅仅是’Gre

发布时间:2020-12-13 20:42:25 所属栏目:百科 来源:网络整理
导读:我进入专业软件开发已有4个月. TDD在我公司GO-JEK是不可谈判的. 以下是我的观察:人们倾向于首先编写代码,然后为其编写测试.显然,对于具有4 – 5年s / w开发经验且之前没有遵循TDD的人来说,这更方便. 那么,人们首先编写失败的测试,然后编写代码来传递它的原
我进入专业软件开发已有4个月. TDD在我公司GO-JEK是不可谈判的.
以下是我的观察:人们倾向于首先编写代码,然后为其编写测试.显然,对于具有4 – 5年s / w开发经验且之前没有遵循TDD的人来说,这更方便.
那么,人们首先编写失败的测试,然后编写代码来传递它的原因是什么?为什么人们不首先编写代码然后为它添加测试?
我们可以在任何一种方式进行重构
这是一个很好的问题.既然我们最终希望我们的测试通过,为什么不写它们以便它们首先传递?

答案是我们真的希望我们的测试能够推动开发.我们希望测试首先出现.因为当我们编写需要某些功能的测试时,这是所需内容的具体表达,并且新功能的定义很明确.最初该功能不存在(因此测试为红色);当我们成功添加功能时,测试为绿色.这是一个干净的决定:功能是否存在且测试正在通过 – 或者不是,测试失败.

如果我们编写测试绿色(已经存在功能),我们可能编写了比实际需要更多的功能.或者我们可能编写了错误的代码 – 功能存在但错误 – 以及相应的错误测试.当我们首先编写测试时,我们目睹了代码库从缺乏必要功能的状态转变为拥有它 – 并且我们非常自信地知道我们已经做到了.

(编辑:李大同)

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

    推荐文章
      热点阅读