单元测试-浅谈单元测试

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

• 测试阶段：详细设计说明文档完成、项目代码编码完成后
• 测试对象：C语音中是函数，Java中是类/方法
• 测试人员：白盒测试工程师或开发工程师
• 测试依据：项目代码和注释+详细设计说明文档（可参考其中的流程图、输入/输出参数值）
• 测试方法：白盒测试为主，黑盒测试为辅
• 动态执行采用的方法：Junit4+PowerMock+Robolectric组合形式

为什么要写单元测试？

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

什么时候写单元测试？

写单元测试的时机不外乎三种情况：

• 一是在具体实现代码之前，这是测试驱动开发（TDD）所提倡的；
• 二是与具体实现代码同步进行。先写少量功能代码，紧接着写单元测试（重复这两个过程，直到完成功能代码开发）。其实这种方案跟第一种已经很接近，基本上功能代码开发完，单元测试也差不多完成了。
• 三是编写完功能代码再写单元测试。我的实践经验告诉我，事后编写的单元测试“粒度”都比较粗。对同样的功能代码，采取前两种方案的结果可能是用10个“小”的单测来覆盖，每个单测比较简单易懂，可读性可维护性都比较好（重构时单测的改动不大）；而第三种方案写的单测，往往是用1个“大”的单测来覆盖，这个单测逻辑就比较复杂，因为它要测的东西很多，可读性可维护性就比较差。

单元测试要写多细？

单元测试不是越多越好，而是越有效越好！进一步解读就是哪些代码需要有单元测试覆盖：

• 逻辑复杂的
• 容易出错的
• 不易理解的，即使是自己过段时间也会遗忘的，看不懂自己的代码，单元测试代码有助于理解代码的功能和需求
• 公共代码。比如自定义的所有http请求都会经过的拦截器；工具类等。
• 核心业务代码。一个产品里最核心最有业务价值的代码应该要有较高的单元测试覆盖率。

目前实际项目中采用的单元测试方法是JUnit4 + PowerMock + Robolectric组合的方法进行单元测试，可以很好的解耦，解决依赖性问题。

经常与单元测试联系起来的另外一些开发活动包括代码走读（Code review)，静态分析（Static analysis)和动态分析（Dynamic analysis)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。

静态分析（static analysis）

静态代码分析（或静态分析）是软件开发中的软件测试活动，其中分析源代码以查找已知与软件错误或安全漏洞相关的结构。当检测到高风险构造时，静态分析工具会报告违规行为，以供开发人员查看和修复。
注：为了从一开始就在您的软件中提高质量，请使用静态分析——软件工程师可以执行的最简单、最有效的方法来防止缺陷并强化代码，同时加快应用程序交付。

常用的静态分析工具：

• Coverity
• Sonarqube
• AndroidLint
• Suresoft 官网链接：https://www.suresoft.com.cn/
• Parasoft 官网链接：https://www.parasoftchina.cn/

代码规范

指针对项目代码的规范性，制定的代码规则表来约束开发者能够开发出更加规范的代码要求。