测试驱动开发
测试驱动开发
什么是TDD（测试驱动开发）
你可能面临过下述一个或者多个痛点、问题或者导致交付失败的原因：
- 部分团队成员无缘参与需求、规范和用户故事的指定
- 大部分测试都是手动，或者根本没有测试
- 虽然使用了自动化测试，但并未检查出真正的问题
- 编写与执行自动化测试的时间太晚，无法给项目带来真正的价值
- 总有更紧迫的问题需要处理，没法腾出专门用于测试的时间
- 无法重构代码，因为担心这样做会破坏既有功能
- 维护成本高
- 客户觉得交付的产品不符合要求
- 文档从来不是最新的
- 害怕部署到生产环境，应为结果无法预期
- 常常无法部署到生产环境，因为运行回归测试的时间太长了
- 团队为搞清楚某些方法或类的作用花费的时间太多了（代码可读性差）
测试驱动开发可以简化重构工作、帮助创建更好的设计以及降低耦合程度。
当要掌握TDD是一个漫长的过程，需要很长的时间和大量的实践。
红灯-绿灯-重构
- 编写一个测试
- 运行所有测试（鉴于测试时在实现前编写的，因此他应该不能通过） 红灯
- 编写实现代码
- 运行所有测试 绿灯
- 重构
- 运行所有测试
会遇到的问题
如果新编写的测试未通过，说明实现不正确，需要修正。
如果其他测试未通过，说明我们破坏了某种功能，必须撤销所有修改。
解决方案
花足够的时间修复代码，让所有测试都通过。
如果不能在几分钟内完成修复，最佳的选择是撤销所做的修改。毕竟修改前一切都是正常的，刚编写的实现显然是带有破坏性的，错误的。所以为何不会到原来的地方，重新考虑正确的实现测试的方式呢？这样我们只是在错误的实现上浪费了几分钟。
总结
你可以使用任务你喜欢的方式编写代码，但要快。一旦进入绿灯状态，我们就知道存在一个由测试构成的安全网，基于这个安全网重构代码。重构结束后，所有测试应当还是能通过的。
如果在重构完成后，有测试未通过，就说明重构破坏了既有功能，应该撤销所做的修改。在重构阶段，我们不修改任何功能，也不引入新的测试，而只是改进代码，并不断运行所有测试，确保没有破坏功能。
重构结束后，在重复整个过程。这个一个无限循环，每次循环都是一个极短的周期。
不要试图让新编写的测试的实现完美无缺，而应只编写足以让这个测试通过的代码就可以了
测试
黑盒测试
黑盒测试（也叫功能测试）将首测软件视为一个黑盒，无需知道其内部构造。这种测试时通过软件界面进行的，旨在确认它们能想预期的那样工作。只要界面的功能未发生变化，测试就应通过，即使内部构造发生变化。这种测试方法提供了外部观察受测软件的结果。
优点
- 可高效测试大块代码段
- 无需访问和理解代码
- 将用户角度和开发人员角度分离
缺点
- 覆盖率有限，因为只执行部分测试场景
- 测试效率低下，因为测试人员对软件内部构造一无所知
- 测试缺乏针对性,因为测试人员对应用程序的了解有限
自动化黑盒测试依赖于某种形式的自动化，如行为驱动开发（BDD）
白盒测试
白盒测试查看受测软件的内部，并将由此获得的知识用于测试过程。例如，如果在特定条件下应引发异常，可能需要在测试中重现这种条件。白盒测试要求测试人员了解系统的内部结构，同时具备编程技能；它提供从内部观察受测软件的结果。
优点
- 可高效找出错误和问题
- 知道受测软件的内部构造有助于进行详细测试
- 能够发现隐藏的错误
- 有助于优化代码
- 由于知道软件的内部构造，可最大限度的提高测试覆盖率
缺点
- 可能无法发现未实现或缺失的功能
- 需要对受测软件的内部构造有大致认识
- 需要访问代码
- 测试通常与产品代码的实现紧密耦合，导致重构代码后原本应该通过的测试未能通过测试
更好的测试
需求（规范和用户故事）是在实现需求的代码之前编写的，因此它们定义了代码。
对于测试来说，如果它们实在代码之后编写的，那么是代码（以及其实现的功能）定义了测试。由既有应用程序定义的测试有失偏颇，倾向于确认代码的功能，而不是检查客户的需求是否得到了满足，或者说代码的行为是否符合预期.
模拟
使用模拟对象（mock）可以规避外部依赖（数据库、Web服务器、外部API等）。
通过模拟外部依赖，可大幅度提高测试测试，但想要轻松使用模拟对象就必须分离关注点以优化代码
可执行文档
TDD另一个很有用的方面是文档。要搞清楚代码时干什么的，通过查看测试了解比查看实现了解要容易的多。
传统软件文档存在的主要问题是，它们通常不是最新的。一部分代码发生变化后，文档便不再反应实际情况。几乎任何类型的文档都是如此，需求和测试用例受到的影响最大。
需要为代码编写文档通常意味着代码本身写得不好。另外，不管你如何努力，文档都必然会过期。
可通过阅读代码来了解系统细节，其他类型的文档提供快速指南和概述。非代码文档应回答诸如“系统的总体目标是什么” “系统使用了那些技术”等问题，而其他方面，代码就是“圣经”。
实现代码提供了所需要的所有细节，而测试代码描述了产品代码背后的意图。
测试就是可执行的文档，而TDD是创建和维护这种文档的最常见的方式。
无需调试
在编写代码前编写测试，并且测试代码覆盖率很高的情况下，我们完全可以相信应用程序将会像预期的那样工作。如果发现bug，我们也可以轻松找出它们，只需要查看未被测试覆盖的代码即可。
测试本身可能没有涵盖某些情况。这种情况下，应对措施是编写额外的测试。
测试代码覆盖率很高的情况下，与逐行调试直到找到bug相比，通过测试找到导致bug的原因要快很多。