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

单元测试 – 编写源代码之前或之后的TDD和测试?

发布时间:2020-12-14 05:00:45 所属栏目:百科 来源:网络整理
导读:我已经看过许多关于为什么测试驱动开发是好的文章,它减少了开发时间等等.但在搜索了很多论坛后,我仍然没有得到TDD的具体优势.我并不是说测试是一件坏事,但我的观点是,如果我在编写源代码后编写单元测试而不是像TDD建议那样反之亦然.两个测试用例一旦完成就会
我已经看过许多关于为什么测试驱动开发是好的文章,它减少了开发时间等等.但在搜索了很多论坛后,我仍然没有得到TDD的具体优势.我并不是说测试是一件坏事,但我的观点是,如果我在编写源代码后编写单元测试而不是像TDD建议那样反之亦然.两个测试用例一旦完成就会像回归测试一样.在尝试在遗留代码中跟踪TDD时,我也遇到了很多问题.我想现在大多数代码都是遗留代码,我们必须在没有预先存在的测试的情况下修改代码.此外,TDD仅限于单元测试,甚至仅限于系统级和集成测试.我无法想象如何在不编写源代码的情况下进行集成测试.

解决方法

我不会说TDD会缩短开发时间.它甚至可能更长.但TDD导致“干净的代码有效”.软件在单元测试的同时增长,而不是一个接一个地增长,因此在编写后立即进行测试.这给开发者带来了信心以及对“他所处的位置”的一个好主意,因为他知道他到目前为止所完成的工作是“完成了”.

事后写单元测试也很难.作者“Working effectively with legacy code”(一个非常好的资源BTW)甚至说没有单元测试编写的代码确实是遗留代码.

Also is TDD limited to unit tests only
or even system level and integration
tests. I am just not able to imagine
how we can do integration tests
without writing source code.

TDD是一种开发技术,它不是要取代其他类型的测试.

然而,可以在要测试的代码存在之前编写集成测试.这允许询问自己如何测试将要生成的代码.

(编辑:李大同)

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

    推荐文章
      热点阅读