因为敏捷开发和TDD运动，许多程序员都开始在项目开发中，同步开发自动化单元测试，就如我现在手上的项目一样，因为业务交叉比较大，经常导致迭代过程中，对某个模块的修改，影响系统其它的部分，在测试过程中，甚至被测试遗漏的地方，在线上暴露问题，导致项目较大的迭代风险和问题排查成本。最近项目组在考虑补充单元测试来覆盖关键的业务代码，来降低相关问题的出现的概率。本章主要是讲解一些关于编写好的测试的更细微但却更重要的点。
1.TDD三定律
定律一、在编写不能通过的单元测试前，不可编写生产代码。
定律二、只可编写刚好无法通过的单元测试，不能编译也算不过。
定律三、只可编写刚好足以通过当前失败测试的生产代码。
严格按照这个三个定律写程序，测试将覆盖所有的生产代码，但是测试的代码量将接近生产代码量，导致令人生畏的关联问题，所以为了自己不会为了解决生产代码的问题又陷入测试代码管理问题，编写好的测试代码的重要性就得到了体现。
2.保持测试代码整洁
测试代码的维护同样应该准守生产代码的质量标准，如果在测试代码的编写过程中，随性而为，认为只要测试代码能够覆盖生产代码就可以了，认为有就可以了，这样的想法是极度危险的，因为测试代码必须随着生产代码的演进而修改，测试越脏，就越难修改，最终测试代码的维护也会需要巨大的成本，而结果只会是导致团队扔掉整个测试代码组。没了测试代码组，你就会失去曾经所拥有的一切好处，可扩展性、可维护性、可复用性，因为有测试代码，你可以毫无顾虑的进行代码优化，修改，甚至架构改进，因为测试代码可以为你保驾护航。所以，一定要认定，测试代码和生产代码一样重要，它也需要和正式代码一样，需要规范，思考，设计，保持整洁。
3.构造-操作-检验
可读性、可读性、可读性，重要的事说三遍，在测试代码编写过程中，一定要保证它和生产代码一样：明确、简单和足够的表达力，用尽可能少的文字表达大量的内容。在测试代码编写的过程中，要尽可能的隐藏恼人的细节，测试直达目的，这个有一个很好的编写模式，可以将没一个测试清晰的分为三个环节。
构造（build）：构造测试数据
操作（operate）：操作测试数据
检验（check）：检验操作
4.每个测试一个断言
就像之前所说的函数规范一样，函数应保持其整洁性，尽量保证一个函数只做一件事，测试也一样，我们应尽量保证每个测试都有且只有一个断言，明确每个测试函数所要覆盖的的功能。
5.F*I*R*S*T
快速（Fast）测试应该足够块，因为如果测试太慢，会严重降低你运行测试代码的频率，也就会拖延问题发现的时间及修改的时间，不断累积
独立（Independent）测试应该相互独立，某个测试不应该为下一个测试设定条件。
可重复（Repeatable）测试应该可以在任何环境中通过，甚至是没有网络的环境下
自足验证（Self-Validating）测试应该有boolean值输出，无论成果获失败，都不应该通过查看日志文件来确认
及时（Timely）测试应及时编写，单元测试应该恰好在使其通过的生产代码之前编写、
523
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
