TDD

为什么这么做 ?

• 单元测试是重构代码的必要条件。
• 完善的测试可以尽早地发现问题。
• 测试可以让你以最小的代价地去尝试的。
• 实验表明，更多的测试往往是更有效率的。
• TDD 可以让你写出模块化，灵活和可扩展的代码。
• 测试覆盖率可以作为合并的标准，有利于控制代码质量
• TDD 可以规避不必要的代码，只需编写最少可通过测试的代码即可。
• 开发者需考虑函数如何被调用，所以在实现之前必须考虑接口的设计。

最佳实践

1. 添加一个测试：测试驱动开发中，每个新的功能都是从编写一个测试开始的，测试定义了一个简单的功能或者是其实现。开发人员必须清楚地理解功能的规范和要求。如果不清楚就要去查看用例和用户故事。它让开发者专注于需求，而不是直接写代码,这是一个微妙但重要的区别。
2. 运行所有的测试：观察新的测试是否通过，如果新的测试通过了说明，需要的函数已经存在或者这个测试设计的不合理。新的测试应该会和预想的一样失败。当通过了新的测试，会增加对自己编码的信心。
3. 编写代码：编写尽可能少的代码去，让测试通过。现在写的代码可能不够优雅和完美，不过没关系，先通过测试，后面再重构。
4. 运行测试：如果所有的测试都通过了，那么你就可以很自信地说完成了任务。若果没有通过，就根据日志，调整代码来通过测试。
5. 重构代码：这一步很重要。为了通过测试，代码可能写得不够优雅。有多处重复的地方，命名方式不符合代码规范，可读性不好等。这可能需要大量的修改，甚至重新实现。这时，测试就可以清楚地展示重构是否正确。
6. 重复以上步骤

测试结构

  有效的测试结构会所有的操作都会完成，也会提高测试的可读性和执行的平滑性。一致的结构有助于建立一个自我记录的测试。常用的测试结构有以下四个部分：

1. 初始化：准备测试所需的环境。
2. 执行：执行测试，输出日志和结果。
3. 确认：确保所有的测试都通过了。
4. 清理：恢复环境到测试开始前的状态，避免干扰其他测试。

  可以使用表格测试法，增加不同类型的测试用例来发现未知的问题。建议将测试代码和生产代码同等对待。测试代码必须是可读的，可维护的并且要覆盖正确的情况，和出错的情况。团队成员可以一起回顾测试代码来分享高效的技术和发现不好的习惯。

反模式

• 单个测试时间过长
• 测试过于拘泥于实现的细节
• 有的测试用例需要依赖其他的测试
• 测试的运行有先后顺序限制
• 测试依赖操作系统特定的状态
• 测试精确地执行行为或性能