1.测试驱动开发
瀑布模型的最后开发人员会乱作一团，而缩短开发周期是一种减少问题的方案
测试驱动开发（TDD）是一种增量式软件开发技术。
简单说明及在没有失败的单测前提下不写产品代码。测试要小且自动化。
TDD操作步骤
- 增加一个小测试。
- 运行所有测试并期待新的测试失败，也可能压根编译不过。
- 为了让测试通过做一些小改动。
- 运行测试并期待测试通过。
- 重构，移除重复并改进代码的表达方式。
针对嵌入式开发
嵌入式开发者最常用的借口就是对于硬件的依赖。原则上对于硬件的依赖和对数据库的依赖看起来没什么两样。
2.测试驱动开发的工具和约定
Unity CppUTest
四阶段模式
- 建立：创建测试的前提条件
- 运行：对系统进行操作
- 验证：检查预期的输出
- 拆卸：把被测系统恢复到测试前的初始状态
3.开始一个C语言模块
模块：一个完备的部分，有明确定义的接口，实现方式为ADT抽象数据类型
单一实例模型：选用静态的只在.c文件中可见的变量，访问方法是通过.h中间的接口函数
多实例模型：typedef struct CircularBufferStruct *CircularBuffer在头文件声明，数据成员的定义放在.c中
1.TDD创建C模块需要用到的文件有：
- 头文件：定义模块接口
- 源文件：包含接口实现
- 测试文件：包含测试用例
- 模块初始化及清理函数
2.写一个测试列表
报酬递减原则：一旦写下几个测试，其他的会很容易想到。当进展很慢时，说明已经到达报酬递减的边缘，这是一个停止写测试列表转而测试驱动设计的好时机。
3.写第一个测试
通过编写LedDriver测试流程来体现如何实际操作TDD。
- 建立测试文件，放在与产品不同的目录下。
- 构建并编译运行测试，得到正确的输出。TEST_GROUP->TEST_CASE
- 让测试用例检查真正有用的东西。
依赖注入
TDD要求CUT[code under test]必须独立与硬件，因此在设计用例时需要考虑为驱动程序伪造环境，如上文中采用u16变量检查16个灯的状态.不要让编码跑在测试前面
忍住不写已经知道的代码颇具挑战性，但是坚持让编码在测试后面这样的原则就能产生被全面测试过的代码。
4.先测试接口再测试内部实现
关注接口，意味着从外向内开发代码。测试作为接口的首个用户，从调用者的角度给出了开发代码的使用方式。
案例总结：先增加一个测试用例，然后增加头文件接口声明，其次增加.c文件的函数骨架，最终进行函数骨架内容填充。
5.增量式前进
DTSTTCPW:先仿冒再建造
保持小而专注的测试
绿了之后即重构
6.测试驱动开发者的状态机
7.测试要做到FIRST
- Fast【快速的】
- Isolated【独立的】
- Repeatable【可重复的】
- Self-verifying【自校验的】
- Timely【及时的】
4.一路测试直到完成
当你发现自己已经在一个坑里，就不要再挖了吧！
