网站建设div设置圆角,公众微信网站建设,个人网站程序下载,网站点击率代码前言
很多工程师对重构这种做法是很认同的#xff0c;面对项目中的烂代码#xff0c;也想重构一下#xff0c;但有担心重构之后出问题#xff0c;出力不讨好。确实#xff0c;如果你需要重构的代码是别的同事开发的#xff0c;你不是特别熟练#xff0c;在没有任何保障…前言
很多工程师对重构这种做法是很认同的面对项目中的烂代码也想重构一下但有担心重构之后出问题出力不讨好。确实如果你需要重构的代码是别的同事开发的你不是特别熟练在没有任何保障的情况下重构引入 bug 的风险还是挺大的。
那如何保证重构不出错呢
你需要掌握各种设计思想、设计原则、设计模式还需要对所重构的业务和代码有足够的了解。除了这些个人能力因素外最可落地执行、最有效的保证重构不出错的手段应该是单元测试了。当重构完成之后如果新的代码仍然能通过单元测试那就说明代码原有逻辑的正确性未被破坏原有的外部可见行为未变符合《设计模式学习笔记 - 规范与重构 - 1.什么情况下要重构重构什么又该如何重构》中对重构的定义。
今天我们来学习下单元测试。学习内容包括
什么是单元测试为什么要写单元测试如何编写单元测试如何在团队中推行单元测试 什么是单元测试
单元测试由工程师自己来编写用来测试自己写的代码的正确性。我们常常将它跟集成测试放到一起来对比。单元测试相对集成测试来说测试的粒度更小。
集成测试的测试对象是整个系统或者某个功能模块比如用户注册、登录功能是否正常是一种端到端的测试。而单元测试的测试对象是类或者函数用来测试一个类或一个函数是否按照预期的逻辑执行。这是代码层级的测试。
举个例子来解释下。
public class Text {private String content;public Text(String content) {this.content content;}/*** 将字符串转化成数字忽略字符串中的首尾空格* 如果字符串中包含除首尾空格之外的非数字字符则返回null*/public Integer toNumber() {if (content null || content.isEmpty()) {return null;}// 省略代码实现...return null;}
}如果我们要测试 Text 类中的 toNumber() 函数的正确性应该如何编写单元测试
为保证测试的全面性针对 toNumber() 函数我们要设计下面这样几个测试用户
入股字符串只包含数字“123”toNumber() 函数输出对应的整数123。如果字符串是空或 nulltoNumber() 函数返回 null。如果字符串包含收尾空格“ 123”“123 ”“ 123 ”toNumber() 返回对应的整数123。如果字符串包含多个收尾空格“ 123 ”toNumber() 返回对应的整数123。如果字符串包含非数字字符“123a4”“123 4” toNumber() 返回 null。
当我们设计好测试用例后剩下的就是将其翻译成代码。代码贴在下发你可以参考看一下。
public class Assert {public static void assertEquals(Integer expectedValue, Integer actualValue) {if (expectedValue ! actualValue) {String msg String.format(Test failed, expected: %d, actual: %d, expectedValue, actualValue);System.out.println(msg);} else {System.out.println(Test passed);}}public static boolean assertNull(Integer actualValue) {boolean isNull actualValue null;if (isNull) {System.out.println(Test passed);} else {System.out.println(Test failed, the value is not null: actualValue);}return isNull;}
}public class TestCaseRunner {public static void main(String[] args) {System.out.println(Run testToNumber());new TextTest().testToNumber();System.out.println(Run testToNumber_nullOrEmpty());new TextTest().testToNumber_nullOrEmpty();System.out.println(Run testToNumber_containsLeadingAndTrailingSpaces());new TextTest().testToNumber_containsLeadingAndTrailingSpaces();System.out.println(Run testToNumber_containsMultiLeadingAndTrailingSpaces());new TextTest().testToNumber_containsMultiLeadingAndTrailingSpaces();System.out.println(Run testToNumber_containsInvalidCharaters());new TextTest().testToNumber_containsInvalidCharaters();}
}public class TextTest {public void testToNumber() {Text text new Text(123);Assert.assertEquals(123, text.toNumber());}public void testToNumber_nullOrEmpty() {Text text1 new Text(null);Assert.assertNull(text1.toNumber());Text text2 new Text();Assert.assertNull(text2.toNumber());}public void testToNumber_containsLeadingAndTrailingSpaces() {Text text1 new Text( 123);Assert.assertEquals(123, text1.toNumber());Text text2 new Text(123 );Assert.assertEquals(123, text2.toNumber());Text text3 new Text( 123 );Assert.assertEquals(123, text3.toNumber());}public void testToNumber_containsMultiLeadingAndTrailingSpaces() {Text text1 new Text( 123);Assert.assertEquals(123, text1.toNumber());Text text2 new Text(123 );Assert.assertEquals(123, text2.toNumber());Text text3 new Text( 123 );Assert.assertEquals(123, text3.toNumber());}public void testToNumber_containsInvalidCharaters() {Text text1 new Text(123a4);Assert.assertNull(text1.toNumber());Text text2 new Text(123 4);Assert.assertNull(text2.toNumber());}
}为什么要写单元测试
单元测试除了能有效地为重构保驾护航之外也是保证代码质量最有效的两个手段之一另一个是 Code Review。单元测试有以下几点好处。
1.单元测试能有效地帮助你发现代码中的 BUG
能够写出 bug free 的代码是判断工程师编码能力的重要标准之一。即便是非常有经验的工程师通过编写单元测试也常常会发现代码中的很多考虑不全的地方。
在尽管现在的开发模式都是“快、糙、猛”对单元测试根本没有要求但是我们应该自己坚持为自己提交的每一份代码都编写完善的单元测试这样可以让我们编写的代码几乎是bug free 的。这会节省很多 fix 低级 buf 的时间能够有时间去做其他有意义的事情。
可以这么说坚持编写单元测试是保证我们代码质量的一种 “杀手锏”也是帮助工程师拉开与其他人差距的一个小秘密。
2.写单元测试能发现代码设计上的问题
代码的可测试性是评判代码质量的一个重要标准。对于一段代码如果很难为其编写单元测试或者单元测试写起来很吃力需要依靠单元测试框架里很高级的特性才能完成那玩玩就意味着代码设计得不够合理比如没有使用依赖注入、大量使用静态函数、全局变量、代码高度耦合等。
3.写单元测试是对集成测试的有力补充
程序运行的 bug 往往出现在一些边界条件、异常情况下比如除数未判空、网络超时。而大部分异常情况都比较难在测试环境中模拟。而单元测试可以利用下一节课中讲到的 mock 方式控制 mock 的对象返回我们需要模拟的异常来测试代码在这些异常情况的表现。
尽管单元测试无法完全替代集成测试但如果我们能保证每个类、每个函数都能按照我们的预期来执行底层 bug 少了那组装起来的整个系统出现问题的概率也就相应减少了。
4.写单元测试的过程本身就是代码重构的过程
上一节课《设计模式学习笔记 - 规范与重构 - 1.什么情况下要重构重构什么又该如何重构》中我们提到要把持续重构作为开发的一部分来执行那些单元测试实际上就是落地执行持续重构的一个有效途径。设计和实现代码的时候我们很难把所有问题都考虑清楚。
而编写单元测试就相当于对代码的一次自我 Code Review在这个过程中我们可以发现一些设计上的问题比如代码设计的不可测试以及代码编写方面的问题比如一些边界条件处理不当等然后针对性的进行重构。
5.阅读单元测试能帮助你快速熟悉代码
阅读代码最有效的手段就是先了解它的业务背景和设计思路然后再去看代码这样代码读起来就会轻松很多。但据我了解程序员都不怎么喜欢写文档和注释而大部分程序员写的代码又很难做到“不言自明”。在每文档和注释的情况下单元测试就起到了替代作用。单元测试用例实际上就是用户用例反映了代码的功能和如何使用。借助单元测试我们不需要深入的阅读代码便能知道代码实现了什么功能有哪些特殊情况需要考虑有哪些边界条件需要处理。
6.单元测试是 TDD 可落地执行的改进方案
测试驱动开发Test-Driven Development简称 TDD是一个经常被提及但很少被执行的开发模式。它的核心指导思想是测试用例先于代码编写。不过要让程序员能彻底地接受和习惯这种开发模式还是挺难的。
个人觉得单元测试就是对 TDD 的一种改进方案先写代码紧接着写单元测试最后根据单元测试反馈出来问题再回过头去重构代码。这个开发流程更加容易被接受更加容易执行落地而且又兼顾了 TDD 的优点。
如何编写单元测试
前面在讲什么是单元测试时我们举了一个 toNumber() 函数写单元测试的例子。根据那个例子我们可以总结得出写单元测试就是针对代码设计覆盖各种输入、异常、边界条件的测试用例并将这些测试用例翻译成代码的过程。
把测试用例翻译成代码的时候可以利用单元测试框架来检测测试代码的编写。比如Java 中比较出名的单元测试框架有 Junit、TestNgG、Spring Test 等。这些框架提供了通用的执行流程比如执行测试用例的 TestCaseRunner和工具类库比如各种 Assert 判断函数等。借助它们我们变系诶测试代码的时候只需要关注测试用例本身的编写即可。
针对 toNumber() 函数的测试用例我们利用 JUnit 单元测试框架爱重新实现以下具体代码如下所示。和之前没有利用测试框架的实现方式对比以下看看是否简化了很多呢
import org.junit.Test;
import org.junit.Assert;public class TextTest {Testpublic void testToNumber() {Text text new Text(123);Assert.assertEquals(Integer.valueOf(123), text.toNumber());}Testpublic void testToNumber_nullOrEmpty() {Text text1 new Text(null);Assert.assertNull(text1.toNumber());Text text2 new Text();Assert.assertNull(text2.toNumber());}Testpublic void testToNumber_containsLeadingAndTrailingSpaces() {Text text1 new Text( 123);Assert.assertEquals(Integer.valueOf(123), text1.toNumber());Text text2 new Text(123 );Assert.assertEquals(Integer.valueOf(123), text2.toNumber());Text text3 new Text( 123 );Assert.assertEquals(Integer.valueOf(123), text3.toNumber());}Testpublic void testToNumber_containsMultiLeadingAndTrailingSpaces() {Text text1 new Text( 123);Assert.assertEquals(Integer.valueOf(123), text1.toNumber());Text text2 new Text(123 );Assert.assertEquals(Integer.valueOf(123), text2.toNumber());Text text3 new Text( 123 );Assert.assertEquals(Integer.valueOf(123), text3.toNumber());}Testpublic void testToNumber_containsInvalidCharaters() {Text text1 new Text(123a4);Assert.assertNull(text1.toNumber());Text text2 new Text(123 4);Assert.assertNull(text2.toNumber());}
}对于如何使用这些单元测试框架大部分框架都给出了非常详细的官方文档你可以自行查阅。这些东西理解和掌握起来没有太大难度所以这不是本节课的重点。关于如何编写单元测试我希望给你一些经验总结。
1.编写单元测试真的很耗时吗
尽管单元测试的代码可能是被测试代码本身的 1~2 倍写的过程很繁琐但并不是很耗时。毕竟我们不需要考虑太多代码设计上的问题测试代码实现起来也比较简单。不同测试用例之间的代码差别可能并不是很大简答的 copy-paste 改改就行。
2.对单元测试的代码质量有什么要求吗
单元测试比较不会在生产线上运行而且每个类的测试代码也比较独立基本不相互依赖。所以相对于被测代码我们对单元测试代码的质量可以放低一些要求。命名稍微有些不规范代码稍微有些重复也都是没有问题的。
3.单元测试只要覆盖率高就够了吗
单元测试覆盖率是比较容量量化的指标常常作为单元测试写得好坏的评判标准。有很多工具专门用来做覆盖率统计比如JaCoCo、Cobertura、Emma、Clover。覆盖率的计算方式有很多种比较简单的是语句覆盖稍微高级点的有条件覆盖、判定覆盖、路径覆盖。
不管覆盖率的计算方式如何高级将覆盖率作为衡量单元测试质量的唯一标准是不合理的。实际上更重要的是要看测试用例是否覆盖了所有可能的情况特别是一些 corner case。我来举个简单的例子解释下。
像下面这段代码我们只需要一个测试用例就可以做到覆盖率 100%比如 cal(10.0, 2.0)但并不代表测试足够全面了我们还需要考虑当除数等于 0 的情况下代码执行是否符合预期。
public double cal(double a, double b) {if (b ! 0.0) {return a/b;}
}实际上过度关注单元测试的覆盖率会导致开发人员为了提高覆盖率写很多没有必要的测试代码比如 get、set 方法非常简单没有必要测试。从过往的经验上来讲一个项目的单元测试覆盖率在 60~70% 即可上线。如果项目对代码质量要求比较高可以适当提高单元测试覆盖率的要求。
4.单元测试都需要了解代码的实现逻辑吗
单元测试不要依赖被测试函数的具体实现逻辑它只关心被测函数实现了什么功能。我们切不可为了追求覆盖率逐行阅读代码然后针对实现逻辑编写单元测试。否则一旦对代码进行重构在代码的外部行为不变的情况下对代码的实现逻辑进行了修改那原本的单元测试都会运行失败也就起不到为重构保驾护航的作用了也违背了我们写单元测试的初衷。
5.如何选择单元测试框架
写单元测试本身不需要太复杂的技术大部分单元测试框架都能满足。在公司内部起码团队内部需要统一单元测试框架。
如果自己写的代码用已经选定的单元测试框架无法测试那多半是代码写的不够好代码的可测试性不够好。这个时候我们要重构自己的代码让其更容易测试而不是去找另一个更加高级的框架。
如何在团队中推行单元测试为什么单元测试难以落地执行
虽然单元测试是保证重构不出错的有效手段也有很多人已经认识到单元测试的测试的重要性。但是有多少项目是完善的、高质量的单元测试呢据我了解非常少包括一些大公司的项目。所以 100% 落实执行单元测试是件 “知易行难” 的事。
写单元测试确实是一件考验耐心的活儿。一般情况下单元测试的代码量要大于被测试代码量甚至是要多出好几倍。很多人往往会就饿得写单元测试比较繁琐并且没有太多挑战而不愿意去做。很多团队和项目在刚开始推行单元测试的时候还比较认真执行得比较好。但当开发任务紧了之后就开始放低对单元测试的要求一旦出现 “破窗效应”慢慢地大家就都不写了这种情况很常见。
还有一种情况就是由于历史遗留问题原来的代码都没有写单元测试代码已经堆砌到十万行了不可能再一个一个去补单元测试。这种情况下我们首先要保证新写的代码都要有单元测试其次每次在改动到某个类时如果没有单元测试就补上不过这要求工程师们有足够的主人翁意识。
此外还有人觉得有了测试团队写单元测试就是浪费时间没有必要。写好代码直接提交然后丢给黑盒测试狠命去测测出问题就反馈给开发团队再修改测不出问题就留在线上除了问题再修复。
在这样的开发模式下团队往往觉得没有必要写单元测试但如果我们把单元测试写好、做好 Code Review重视起代码质量其实可以很大程度上减少黑盒测试的投入。
总结
1.什么是单元测试
单元测试是代码层面的测试由研发自己编写用于测试 “自己” 编写的代码的逻辑的正确性。单元测试顾名思义是测试一个 “单元”有别于集成测试这个 “单元” 一般是类或函数而不是模块或系统。
2.为什么要写单元测试
写单元测试的过程本身就是代码 Code Review 和重构的过程能有效地发现代码中的 bug 和代码设计上的问题。除此之外单元测试还是对集成测试的有力补充还能帮助我们快速熟悉代码是 TDD 可落地执行的改进方案。
3.如何编写单元测试
写单元测试就是针对代码设计各种测试用例以覆盖各种输入、异常、边界情况并将其翻译成代码。我们可以利用一些测试框架来简化单元测试的编写。除此之外对于单元测试我们需要建立以下正确的认知
编写单元测试尽管繁琐但并不太耗时。我们可以稍微放低对单元测试代码质量的要求。覆盖率作为衡量单元测试的唯一标准是不合理的。单元测试不要依赖被测代码的具体实现逻辑。单元测试框架无法测试多半是因为代码的可测试性不好。
4.单元测试为何难落地执行
一方面写单元测试本身比较繁琐技术挑战不大很多程序员不愿意去写另一方面国内研发比较偏向 “快、糙、猛”容易因为开发进度紧导致单元测试的执行虎头蛇尾。最后关键问题还是团队没有建立对单元测试正确的认识觉得可有可无单靠督促很难执行得很好。
