浅谈TDD（测试驱动开发）
开发
什么是TDD
Test-Driven Development，测试驱动开发。
在持续迭代的项目中，为了适应业务的变迁我们不得不持续进行代码重构，而重构带来了未知的风险，大多数开发者不喜欢做这种工作。
测试驱动开发可以尝试解决这个问题，测试驱动开发的核心在于测试驱动，首先完成测试代码的编写，然后编写业务逻辑代码满足测试用例，在这种情况下，业务逻辑的代码重构可以很灵活。
TDD的优点
- 需求在一开始就被拆分明确。
- 避免过度设计带来的浪费。
- 完备的测试使重构更加灵活。
- 保证了代码质量，针对关键代码的测试集，以及不断完善的测试用例，为迅速发现、定位bug提供了条件。
- 对代码的可测试性提出了高要求，有利于团队分工。
TDD的缺点
- 加大了代码的编写量。
- 对功能品质的要求放慢了开发速度。
- 对UI开发来说，单元测试比较困难，很难执行TDD的方法。
TDD的原则
- 测试隔离：不同代码的测试应该相互独立，一个模块对应一个测试模块。
- 一顶帽子：开发过程包含多种工作，如：编写测试代码、编写产品代码、代码重构等。做不同的工作时，应专注于当前的角色，不要过多考虑其他方面的细节。
- 测试列表：代码的功能点可能很多，并且需求可能是陆续出现的，任何阶段想添加功能时，应先把相关功能点加到测试列表中，然后继续手头工作，避免干扰当前进行的工作。
- 测试驱动：即利用测试来驱动开发，是TDD的核心。要实现某个功能，要编写某个类或某个函数，应首先编写测试代码，明确这个类、这个函数如何使用，如何测试，然后在对其进行设计、编码。
- 可测试性。功能代码设计、开发时应该具有较强的可测试性。其实遵循比较好的设计原则的代码都具备较好的测试性。比如比较高的内聚性，尽量依赖于接口等。
- 及时重构。无论是功能代码还是测试代码，对结构不合理，重复的代码等情况，在测试通过后，及时进行重构。
- 小步前进。把所有的规模大、复杂性高的工作，分解成小的任务来完成。对于一个类来说，一个功能一个功能的完成，如果太困难就再分解。每个功能的完成就走测试代码－功能代码－测试－重构的循环。通过分解降低整个系统开发的复杂性。
TDD的过程
- 明确当前要完成的功能列表。
- 完成尽可能多的针对此功能的测试用例编写。
- 测试代码编译不通过。
- 编写足够的功能代码。
- 测试通过。
- 对代码进行重构，移除重复啰嗦的代码，保证测试通过。
- 重复以上步骤。
总结
测试驱动开发不是一个新话题了，TDD能有效的提高开发质量，副作用是会影响开发进度。在TDD中，测试的责任更多的被分配给开发者而非测试人员，这与我们的习惯不同。另外在我的理解中，如何写足够多的测试，同时只写刚刚足够的功能代码，也是一个难题，结对编程和及时的CodeReview也许是一个解决方案。
