老司机建议你掌握java编程的单元测试

虽然很多Java书籍或者java基础教程中都会讲到，单元测试是保证重构不出错的有效手段；也有非常多人已经认识到单元测试的重要性。但是有多少项目有完善的、高质量的单元测试呢？真的非常非常少，包括 BAT 这样级别公司的项目。如果不相信的话，你可以去看一下国内很多大厂开源的项目，有很多项目完全没有单元测试，还有很多项目的单元测试写得非常不完备，仅仅测试了逻辑是否运行正确而已。所以，100% 落实执行单元测试是件 “知易行难” 的事。

写单元测试确实是一件考验耐心的活儿。一般情况下，单元测试的代码量要大于被测试代码量，甚至是要多出好几倍。很多人往往会觉得写单元测试比较繁琐，并且没有太多挑战，而不愿意去做。有很多团队和项目在刚开始推行单元测试的时候，还比较认真，执行得比较好。但当开发任务紧了之后，就开始放低对单元测试的要求，一旦出现破窗效应，慢慢的，大家就都不写了，这种情况很常见。

还有一种情况就是，由于历史遗留问题，原来的代码都没有写单元测试，代码已经堆砌了十几万行了，不可能再一个一个去补单元测试。这种情况下，我们首先要保证新写的代码都要有单元测试，其次，每次在改动到某个类时，如果没有单元测试就顺便补上，不过这要求工程师们有足够强的主人翁意识（ownership），毕竟光靠 leader 督促，很多事情是很难执行到位的。

除此之外，还有人觉得，有了测试团队，写单元测试就是浪费时间，没有必要。程序员这一行业本该是智力密集型的，但现在很多公司把它搞成劳动密集型的，包括一些大厂，在开发过程中，既没有单元测试，也没有 Code Review 流程。即便有，做的也是差强人意。写好代码直接提交，然后丢给黑盒测试狠命去测，测出问题就反馈给开发团队再修改，测不出的问题就留在线上出了问题再修复。

在这样的开发模式下，团队往往觉得没有必要写单元测试，但如果我们把单元测试写好、做好 Code Review，重视起代码质量，其实可以很大程度上减少黑盒测试的投入。我在 Google 的时候，很多项目几乎没有测试团队参与，代码的正确性完全靠开发团队来保障，线上 bug 反倒非常少。

以上是我对单元测试的认知和实践心得。现在互联网信息如此的公开透明，网上有很多文章可以参考，对于程序员这个具有很强学习能力的群体来说，学会如何写单元测试并不是一件难事，难的是能够真正感受到它的作用，并且打心底认可、能 100% 落地执行。

重点回顾
单元内容到此就讲完了。我们来一块总结回顾一下重点内容。

1. 什么是单元测试？

单元测试是代码层面的测试，由研发自己来编写，用于测试 “自己” 编写的代码的逻辑的正确性。单元测试顾名思义是测试一个 “单元”，有别于集成测试，这个 “单元” 一般是类或函数，而不是模块或者系统。

2. 为什么要写单元测试？

写单元测试的过程本身就是代码 Code Review 和重构的过程，能有效地发现代码中的 bug 和代码设计上的问题。除此之外，单元测试还是对集成测试的有力补充，还能帮助我们快速熟悉代码，是 TDD 可落地执行的改进方案。

3. 如何编写单元测试？

写单元测试就是针对代码设计各种测试用例，以覆盖各种输入、异常、边界情况，并将其翻译成代码。我们可以利用一些测试框架来简化单元测试的编写。除此之外，对于单元测试，我们需要建立以下正确的认知：

编写单元测试尽管繁琐，但并不是太耗时；
我们可以稍微放低对单元测试代码质量的要求；
覆盖率作为衡量单元测试质量的唯一标准是不合理的；
单元测试不要依赖被测代码的具体实现逻辑；
单元测试框架无法测试，多半是因为代码的可测试性不好。

4. 单元测试为何难落地执行？

一方面，写单元测试本身比较繁琐，技术挑战不大，很多程序员不愿意去写；另一方面，国内研发比较偏向 “快、糙、猛”，容易因为开发进度紧，导致单元测试的执行虎头蛇尾。最后，关键问题还是团队没有建立对单元测试正确的认识，觉得可有可无，单靠督促很难执行得很好。

老司机建议你掌握java编程的单元测试

1. 什么是单元测试？

2. 为什么要写单元测试？

3. 如何编写单元测试？

4. 单元测试为何难落地执行？

相关推荐

发表评论