单元测试实践的主要问题与解决（1）

本文是我在“第十届中国系统与软件过程改进年会广东会场”所作演讲的整理稿，主要分享单元测试的一些要点、单元测试实践的主要问题，以及如何来解决这些问题。

一、单元测试概述

1.1 什么是单元测试

单元测试，就是针对代码单元的独立测试。为什么需要单元测试呢？这是代码的基本特性决定了的。代码有一个基本特性，就是对数据分类处理。

代码通常会有很多的判定。一个判定，就是一次分类。嵌套的判定，会使分类次数的翻倍。

如果我们在写代码的时候，有一个分类漏掉了，就会产生一个Bug；如果一个分类，虽然写了代码，但是处理不正确，也会产生一个Bug。一个函数要没有错误，必须做到两点：1，对数据的分类必须完整；2，每一个分类的处理必须正确。做到了这两点，就可以说，代码的功能逻辑是正确的。

那么，如何检测代码的功能逻辑是否正确呢？

调试，是临时的，且不完整的，例如，一个函数有十种输入，调试能覆盖五六种就不错了。而系统测试，并不针对某个具体的函数，不关注某个函数的功能逻辑是否正确。

要检测某个函数的功能逻辑，就必须要依照分类列出数据，检测代码是否对每一个分类都做了处理，而且每一个分类的处理是否正确。

——这就是单元测试。

1.2 单元测试的基本方法

由上面的分析可以看出，单元测试的基本方法就是：依数据的分类列出输入，执行被测试程序，然后，判断输出是否符合预期。

单元测试能达到什么样的效果呢？那就是：无论别人怎么样，我总是对的！

这里的“别人”，是指关联代码。“我”，是指当前正在编写或测试的代码。单元测试要做到的是，无论关联代码是否有错，都要保证我是对的。具体来说，我要考虑关联代码会产生什么样的数据，这些数据要如何分类处理，只要我的分类和处理是正确的，那么，无论别人怎么样，我总是对的。

1.3 单元测试的效益

单元测试的效益可以说是立竿见影，并且会推动整个开发过程的改进。

首先，单元测试可以保证代码的质量。因为只有单元测试，能够全面检测代码单元的功能逻辑，排除代码中大量的、细小的错误。

其次，排错成本最小。如果在编码阶段同时进行单元测试，排错成本可以忽略不计。但若到了后期，排错成本可能会增长上百倍，要是产品已经到了用户手里，那造成的损失就更难说了。

第三，提升开发效率。单元测试可以让程序行为一目了然，也就是程序行为可视化。什么叫程序行为呢？就是什么输入下，会执行哪些代码，会产生什么输出。如下图，黑色的代码是当前输入下所执行代码。

如果我们写几行代码，就可以看到程序的行为，相当于写文章时上下文可见，这可以促进我们的开发思维。如果我们的思维有了偏差，也可以及时发现。如果代码中有了错误，也可以随时排除。

那么，是不是整个项目的所有代码都做了单元测试，才能得到这些效益呢？不是的。80:20规则，在软件开发过程中也存在。也就是说，80%的代码错误，可能存在于20%的代码中；80%的编码、调试成本，可能会消耗在20%的代码上。这20%，就是算法密集度高的代码，也就是功能逻辑复杂的代码。

这些代码可能只有20%，但是却可能包含了80%的错误，消耗了80%的编码、调试时间，即使只对这部分代码进行单元测试，在提升产品的质量和开发效率方面，也会产生立竿见影的效果。

第四，自动回归。如果没有单元测试，系统测试发现了错误，当然要修改代码，而修改代码可能引入新的错误，又要进行全面的系统测试，这样就可能陷入循环，这通常也是项目延期的主要原因。

如果有了单元测试，修改代码时可以通过回归测试马上检测是否引入了新的错误。所谓回归，就是回复到原来正确的状态。

正是回归测试，使单元测试对整个开发过程的改进都产生积极影响，使项目适应频繁变化的需求。单元测试是敏捷开发的基础和核心，反过来说，有了单元测试，开发过程会自动趋于敏捷。单元测试也降低了后期测试的压力。

本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/

卓越工程之单元测试在行权鉴权中的实践 在去年的时候就读过《重构：改善既有代码的设计》这本在代码重构领域里的经典，当时在读的时候就苦于有这么两点导致只停留在了“读”上面，而缺少实践。
卓越工程之单元测试在行权鉴权中的实践 在去年的时候就读过《重构：改善既有代码的设计》这本在代码重构领域里的经典，当时在读的时候就苦于有这么两点导致只停留在了“读”上面，而缺少实践。
客户端单元测试实践——C++篇 我们团队在手淘中主要负责BehaviX模块，代码主要是一些逻辑功能，很少涉及到UI，为了减少双端不一致问题、提高性能，我们采用了将核心代码C++化的策略。由于团队项目偏底层，测试同学难以完全覆盖，回归成本较高，部分功能依赖研发同学自测，为了提高系统的稳定性，我们在团队中实行了单元测试，同时由于集团客户端C++单元测试相关经验沉淀较少，所以在此分享下团队在做单元测试中遇到的问题与解决思路，希望能对大家所有帮助。
单元测试实践篇：Mock 淘系的技术发展已经有相当一段历史了，在历史的长河中总能沉淀出很多复杂的巨型项目，包罗多个业务，而且往往服务依赖比较复杂；再加上一些特殊环境变量的设置，想要在本地运行、debug 自测这种大型应用的难度越来越高；尤其是对环境不太熟悉的新人而言成本会更高。 这类应用的单元测试不能像微服务化的应用一样，可以方便的将整个 service 在本地 Run Test，但是依靠于日常开发部署环境的远程 debug、日志、Arthas 等工具定位项目自测联调中的问题又会显得格外的笨重，问题修复几秒钟，发布一次 10min 会成为严重的效率瓶颈。 如何高效的自测代码逻辑，如何不启动整个服务就能验证我的目标方
Golang 单元测试：有哪些误区和实践？ 单元测试作为开发的有力武器，应该在软件开发的各个流程中发挥它的价值。原始的开发模式（开发完毕，交给测试团队进行端到端测试）的流程，应该逐步向 devops 的方向转变。本文是一个转型的具体实践过程，以一个实际的业务应用项目为例，介绍了在展开单测实践过程中遇到的一些常见问题的思考，并着重介绍了几种 mock 方法，对于一些相对复杂依赖项较多的业务也可以作为借鉴。
golang 单元测试框架实践 日常开发中, 测试是不能缺少的，每次手动测试非常费时费力，通过单元测试可以达到一次实现多次利用； 单元测试主要是通过模拟业务中的参数，调用我们的函数，然后获取执行结果，再判断结果是否符合规则；同时还可以对某一个方法进行性能分析 在Go 标准库中有一个叫做 `testing` 的测试框架, 可以用于单元测试和性能测试. 它是和命令 `go test` 集成使用的，测试文件是以后缀 `_test.go` 命名的, 通常和被测试的文件放在同一个包中.