保存成功
订阅成功
保存失败,请重试
提交成功

深度解读测试驱动开发(TDD)

¥15会员免费看
Seaborn Lee
4.7
严选 Chat了解严选标准

你是否还在用如下这种方式编写代码?

  • 需求分析,想不清楚细节,管他呢,先开始写。
  • 发现需求细节不明确,去跟业务人员确认。
  • 确认好几次终于写完所有逻辑。
  • 运行起来测试一下,靠,果然不工作,调试。
  • 调试好久终于工作了。
  • 转测试,QA 测出 BUG,打补丁。
  • 终于,代码可以工作了。
  • 一看代码烂的像坨屎,不敢动,动了还得手工测试,还得让 QA 测试,还得加班。

我要介绍的 TDD 编码方式是这样的:

  • 先分解任务,分离关注点。
  • 列 Example,用实例化需求,澄清需求细节。
  • 写测试,只关注需求,程序的输入输出,不关心中间过程。
  • 写实现,不考虑别的需求,用最简单的方式满足当前这个小需求即可。
  • 重构,用手法消除代码里的坏味道。
  • 写完,手动测试一下,基本没什么问题,有问题补个用例,修复。
  • 转测试,小问题,补用例,修复。
  • 代码整洁且用例齐全,信心满满地提交。

本场Chat内容包括:

  1. TDD 的几层含义;
  2. TDD 的本质;
  3. TDD 的好处;
  4. 为什么大部分人 TDD 会失败;
  5. TDD 的正确练习路径。

实录提要:

  • 在一个团队中谁来写单元测试呢,开发还是测试?如何协作?
  • TDD 是否适合界面的开发?
  • 有关于怎样分解任务的策略,拿到一个任务,如何开始第一步?
  • 如何在紧张的工期和完善的单元测试之间进行权衡?
  • 两周一个版本迭代,适合用 TDD 吗?
  • 对于单元测试的 mock,应该针对外部接口进行 mock 吗?
247 人已订阅
会员免费看
¥15 原价订阅
查看文章评论/提问
洛小城2 年前
¥15 就是这篇文章?
tangpeng3 年前
单元测试中有mock和测试桩两种,推荐哪种方式呢?
tangpeng3 年前
一直有一个疑问,tdd过程中是否需要及时重构,我觉得可以先消除怪味道不一定要求及时重构,比如不用着急提提取方法,如果过早提取方法不利于后面观察规律和重构。
林从羽3 年前
在大型的项目中,原代码库基本不遵循单一职责原则,一个方法做四五件事情,可能还依赖全局的状态变量,而我们要实现的方法必须写在中间。而原代码的测试方法一个也有三十到四十行,基本都在准备测试数据,很复杂。我的问题是,在这种测试数据准备很困难的场景下,tdd该如何做?问题再推广一下,在一个项目组中,tdd的实施,与人员素养、团队结构、团队文化、代码库现有设施与设计这四五个因素,有什么样的影响及推广方式呢?
陈志伟3 年前
写单元测试好的实践,及各种单元测试优缺点(使用详解就更好了),望分享下
微信扫描登录
关注提示×
扫码关注公众号,获得 Chat 最新进展通知!
入群与作者交流×
扫码后回复关键字 入群
Chat·作者交流群
入群码
该二维码永久有效
严选标准
知道了
Chat 状态详情
开始预订
预订结果公布17.03.02

预订达标,作者开始写作

审核未达标,本场 Chat 终止

作者文章审核结果公布17.03.13

审核达标,文章发布

审核未达标,本场 Chat 终止

Chat 完结
×
已购列表