实际情况不同含义不同，如 C 语言中单元指一个函数，Java 里单元指一个类。通常在软件开发中，单元就是人为规定的最小的被测功能模块

测试就是检查,用来检验相应的代码是否应该存在它本应该提供的功能,或者是否存在潜在的 BUG

• 允许你对代码做出较任何改变，因为你了解单元测试会在你的预期之中
• 单元测试可以有效地降低程序出现 BUG 的机率；
• 帮助你更深入地理解代码–因为在写单元测试的时候，你需要明确程序所有的执行流程及对应的执行结果等等;
• 允许在任何时候代码重构，而不必担心破坏现有的代码。这使得我们编写程序更灵活;
• 确保你的代码的健壮性，因为所有的测试都是通过了的
• 文档记录。单元测试就是一种无价的文档，它是展示函数或类如何使用的最佳文档，这份文档是可编译、可运行的、并且它保持最新，永远与代码同步。
• 具有回归性。自动化的单元测试避免了代码出现回归，编写完成之后，可以随时随地地快速运行测试，而不是将代码部署到设备之后，然后再手动地覆盖各种执行路径，这样的行为效率低下，浪费时间

1. 在实现代码之前先写测试，这是测试驱动开发（TDD）所提倡的一种方式

2. 实现代码与测试同步进行。先写少量功能代码，紧接着写单元测试（重复这两个过程，直到完成功能代码开发）。其实这种方案跟第一种已经很接近，基本上功能代码开发完，单元测试也差不多完成了

3. 编写完功能代码再写单元测试。我的实践经验告诉我，事后编写的单元测试粒度都比较粗。对同样的功能代码，采取前两种方案的结果可能是用 10 个“小”的单测来覆盖，每个单测比较简单易懂，可读性可维护性都比较好（重构时单测的改动不大）；而第三种方案写的单测，往往是用 1 个“大”的单测来覆盖，这个单测逻辑就比较复杂，因为它要测的东西很多，可读性可维护性就比较差

• 逻辑复杂的、容易出错的、不易理解的，即使是自己过段时间也会遗忘的代码最好增加上单元测试，这样有助于理解代码的功能和需求

• 公共代码最好加上单元测试，比如自定义的所有 http 请求都会经过的拦截器；工具类等。

• 核心业务代码最好加上单元测试，一个产品里最核心最有业务价值的代码应该要有较高的单元测试覆盖率