一、理论上的原则如下
- 快：单元测试是回归测试，可以在开发过程的任何时候运行，因此运行速度必须快。
- 一致性：代码没有改变的情况下，每次运行得结果应该保持确定且一致。
- 原子性：结果只有两种情况：Pass / Fail。
- 用例独立：执行顺序不影响；用例间没有状态共享或者依赖关系；用例没有副作用（执行前后环境状态一致）。
- 单一职责：一个用例只负责一个场景。
- 隔离：功能可能依赖于数据库、web访问、环境变量、系统时间等；一个单元可能依赖于另一部分代码，用例应该解除这些依赖。
- 可读性：用例的名称、变量名等应该具有可读性，直接表现出该测试的目标。
- 自动化：单元测试需要全自动执行。测试程序不应该有用户输入；测试结果应该能直接被电脑获取，不应该由人来判断。
二、规范原则
在实际编写代码过程中，不同的团队会有不同团队的风格，只要团队内部保持有一定的规范即可，比如：
- 单元测试文件名必须以xxx_test.go命名。
- 方法必须是TestXxx开头，建议风格保持一致（驼峰或者下划线）。
- 方法参数必须 t *testing.T。
- 测试文件和被测试文件必须在一个包中。
三、衡量原则
单元测试是要写额外的代码的，这对开发同学的也是一个不小的工作负担，在一些项目中，需要合理的评估单元测试的编写，个人认为我们不能走极端，当然理论上来说全都写是好的，但是从成本，效率上来说我们必须做出权衡，衡量原则有：
- 优先编写核心组件和逻辑模块的测试用例。
- 逻辑类似的组件如果存在多个，优先编写其中一种逻辑组件的测试用例。
- 发现Bug时一定先编写测试用例进行Debug。
- 关键util工具类要编写测试用例，这些util工具适用的很频繁，所以这个原则也叫做热点原则，和第1点相呼应。
- 测试用户应该独立，一个文件对应一个，不同的测试用例之间不要互相依赖。
- 测试用例保持更新。
