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

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

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

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

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

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

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

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

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

1. 什么是单元测试?

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

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

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

3. 如何编写单元测试?

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

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

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

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

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注

关注我们