单元测试检测表 (读书笔记）

1. 带描述化的命名协定 - 考虑一个命名协定，使其具备自描述的风格。所有的测试保持风格的一执行，名称体现明确的目的。像：类名_目的_期待结果

例子： Credentials_UserNameLength_Succeed()

         Credentials_UserNameLength_TooLong_Fail()

2. 测试代码文档化 - 单元测试是测试和验证功能和商务需求。代码自身就是系统的一个活文档。建议使用名称，简洁的代码和最低限度的文档的组合，使单元测试可读、可维护和自描述。

3. 描述性的错误和断言消息 - 使用描述性的信息来改善代码的可读性和创建日志。例如：Content submission failed due to too many spelling errors

4. 采用一个接口驱动设计 - 该接口定义契约， 允许存根(stubs)和黑盒测试.

5. 保持简单 - 单元测试必须简单，清晰和尽量简洁。它必须看成是一个测试和文档方面重要的资产。否则，它可能成为一个可以忽略的维护垃圾。

6. 保持焦点 - 单元测试是聚焦于最小的可测试的代码单元（方法/类/等），不是在系统或者集成层。保持测试和相关的基础结构聚焦在一个单元层，避免测试跨越应用程序或者服务层。

7. 一个逻辑断言 - 每个单元测试必须只有一个逻辑断言。它必须像它的名称那样校验单元的测试。一个逻辑断言可以保含一个或者多个断言语句。

8. 组织和维护测试 - 代码必须像第一类市民被组织和维护, 对等于解决方案的其他部分。单元测试的代码必须基于相同的实践，质量和公司编码需求。

9. 测试好的、坏的和边界情况 - 单元测试必须覆盖全部可能的场景以及尽可能高的覆盖率。测试边界情况和异常是测试者的职责，不是最终用户。