TDD之旅

关于TDD我都经历过什么：

最开始对TDD的理解很表面，只知道TDD就是先写测试，再写实现，由于大家（当然包括我自己）的开发习惯一时间很难改变，TDD并没有真正的在项目里落地，尽管管理者一直大力宣扬TDD的好处。经历过TDD从上而下的推行，最后由于大多数的develop各种原因没有实行起来。。。今年终于有机会领略真正的TDD了，也深刻的理解到了TDD的好处。故事时这样开始的

TDD开发流程

进入RR Team两个月了。本Team专业TDD“二十年”哈。 Team里的每一张story卡都是以TDD的方式，由两个developer pair，完成的。一个人写TestCase，一个人写实现（负责把TestCase跑过）。下面就说说我们team的TDD开发工作流程。

1. tasking：首先拿到story卡，分析需求，拆分成多个tasks，通常每个task会和testcase一一对应，当然要具体需求具体分析。 task的验收标准就是，完成所有的tasks，整个story就算完成了。

2. 和QA开卡，确定要交付的东西，保证大家上下文一致。

3. write test case and run failed

4. write logic code in order to pass test case

5. pass test case

6. 重复第3步和第四步，直到完成所有task

Bug来了：

当拿到一个bug需要修复时，第一件事情就是写测试或者修改之前的测试。 

bug原因：逻辑被遗落了，说明时tasking的时候没有考虑全面，少些了某个task或者时测试用例。 这时候首先要做的就是补上这个测试用例，

        * step1: 补测试用例

        * step2: test failed

        * step3: write logic code

        * step4：test passed

bug原因：现有的 test case不符合业务需求，

        * step1: 修改已有的测试用例

        * step2: test failed

        * step3: write logic code

        * step4：test passed

TDD的好处

保证程序健壮性。

及时反馈(无需启动环境，配置前后端，手动操作页面或者借助工具向服务端发送请求，借助测试框架可以直接运行Test case，省去很多时间)。

每个测试只关注一件事情，明确小目标，避免了开发过程中由于复杂逻辑的实现，而忽略了最终或者最初的需求。可以总结为以下几点：，

(https://www.jianshu.com/p/62f16cd4fef3)

>**降低开发者负担**

通过明确的流程，让我们一次只关注一个点，思维负担更小。

>**保护网**

TDD 的好处是覆盖完全的单元测试，对产品代码提供了一个保护网，让我们可以轻松地 迎接需求变化 或 改善代码的设计 。

所以如果你的项目需求稳定，一次性做完，后续没有任何改动的话，能享受到 TDD 的好处就比较少了。

>**提前澄清需求**

先写测试可以帮助我们去思考需求，并提前澄清需求细节，而不是代码写到一半才发现不明确的需求(自从使用了TDD后代码写到一半才发现这根本不是需求想要的情况基本不会出现，亲身体会)。

>**快速反馈**

>有很多人说 TDD 时，我的代码量增加了，所以开发效率降低了(几年前我对此坚信不疑)。但是，如果没有单元测试，你就要手工测试，你要花很多时间去准备数据，启动应用，跳转界面等，反馈是很慢的。准确说，快速反馈是单元测试的好处。

谁把CI搞红了！！！

将Test case纳入pipeline。这样当有测试失败时，大家会及时发现。说明新的提交破坏了原有的逻辑（这个逻辑被测试覆盖）。