作者：李小波 原文链接：https://www.jianshu.com/p/62f16cd4fef3

以下截取部分文章，说明为什么要TDD

为什么要 TDD

传统编码方式 VS TDD 编码方式

传统编码方式

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

TDD 编码方式

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

    TDD 的好处

    降低开发者负担
    通过明确的流程，让我们一次只关注一个点，思维负担更小。 保护网
    TDD 的好处是覆盖完全的单元测试，对产品代码提供了一个保护网，让我们可以轻松地迎接需求变化或改善代码的设计。
    所以如果你的项目需求稳定，一次性做完，后续没有任何改动的话，能享受到 TDD 的好处就比较少了。 提前澄清需求
    先写测试可以帮助我们去思考需求，并提前澄清需求细节，而不是代码写到一半才发现不明确的需求。 快速反馈
    有很多人说 TDD 时，我的代码量增加了，所以开发效率降低了。但是，如果没有单元测试，你就要手工测试，你要花很多时间去准备数据，启动应用，跳转界面等，反馈是很慢的。准确说，快速反馈是单元测试的好处。

Task

主线任务：

  • 阅读李小波老师的文章，这样你能够形成对TDD基本正确的认知。

支线任务：

  • 在评论区评论你对TDD的一些疑惑