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

深度解读测试驱动开发(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 吗?
275 人已订阅
会员免费看
¥15 原价订阅
关注提示×
扫码关注公众号,获得 Chat 最新进展通知!
入群与作者交流×
扫码后回复关键字 入群
Chat·作者交流群
入群码
该二维码永久有效
严选标准
知道了
Chat 状态详情
开始预订
预订结果公布17.03.02

预订达标,作者开始写作

审核未达标,本场 Chat 终止

作者文章审核结果公布17.03.13

审核达标,文章发布

审核未达标,本场 Chat 终止

Chat 完结
×
已购列表