单元测试的价值 单元测试是一种白盒测试技术,通常由开发人员在编码阶段完成,目的是验证软件代码中的每个单元(方法或类等)是否符合预期,即尽早在尽量小的范围内暴露问题。
我们都知道,问题发现得越早,修复的代价越小。毫无疑问,在开发阶段进行正确的单元测试可以极大地节省时间和金钱。如果跳过单元测试,会导致在后续更高级别的测试阶段产生更高的缺陷修复成本。
如图,假如有一个只包含两个单元 A 和 B 的程序,且只执行端到端测试,如果在测试过程中发现了缺陷,则可能有如下多种原因:
该缺陷由单元 A 中的缺陷引起;
该缺陷由单元 B 中的缺陷引起;
该缺陷由单元 A 和单元 B 中的缺陷共同引起;
该缺陷由单元 A 和单元 B 之间接口的缺陷引起;
该缺陷是测试方法或测试用例的错误导致的。
由此可见,忽略单元测试会导致后续发现缺陷时,要花费较高的成本来确认缺陷原因。
单元测试除了能够在较早阶段识别软件中的错误,它还有如下价值。
反馈速度快:单元测试通常以自动化形式运行,执行速度非常快,可以快速反馈结果,跟持续集成结合起来,形成有效的反馈环。
重构的有力保障:系统需要大规模重构时,单测可以确保对已有逻辑的兼容,如果单元测试都通过,基本上可以保证重构没有破坏原来代码逻辑的正确性。
使更熟悉代码:写单元测试的过程本身就是一个审视代码的过程,可以发现一些设计上的问题(代码设计的不可测试)、代码编写方面的问题(边界条件的处理不当)等。
既然单元测试由开发人员来设计和执行,那作为测试人员是不是就不需要学习这门技术了?不知道你是怎样看待这个想法的,我的观点是:
单元测试只是通常情况下由开发人员完成,并不是绝对的,在一些公司或项目里也存在测试人员完成的情况;
在你负责的模块或服务里,第一级别的测试不是你来完成的,那么你更有必要去了解它的设计思路和执行情况,这能帮助你发现单元测试可能存在的问题点,也有利于你设计和执行后续高级别的测试类型;
开发人员总是不太擅长做测试类的工作,当你掌握了单元测试的技能,你便更有机会去帮助和影响到开发人员,赢得他对你的尊重,也有利于你们更好地合作;
这种想法是测试人员的常见想法,所以掌握单元测试技能在测试人员群体中也会是稀缺技能,因此,掌握它将会获得额外的锻炼机会和个人影响力,要知道,机会总是留给有准备的人。
微服务下的单元测试类型 就像之前课程所说:微服务中最大的复杂性不在于服务本身,而在于微服务之间的交互方式,服务与服务之间常常互相调用以实现更多更复杂的功能。
举个例子,我们需要测试的是订单类(Order)中的获取总价方法(getTotalPrice()),而在该方法中除了自有的一些代码逻辑外,通常需要去调用其他类的方法。比如这里调用的是用户类(User)的优惠等级方法(reductionLevel ())和商品类(Goods)中的商品价格方法(getUnitPrice())。很显然,优惠等级方法或商品价格方法,只要一方有错误,就会导致订单类获取总价方法的测试失败。基于这种情况,可以有两种单元测试类型。
1. 社交型单元测试(Sociable Unit Testing) 如图,测试订单类的获取总价方法(Order.getTotalPrice())时会真实调用用户类的优惠等级方法(User.reductionLevel())和商品类的商品单价方法(Goods.getUnitPrice())。将被测试单元视为黑盒子,直接对其进行测试,这种单元测试称之为社交型单元测试(Sociable Unit Testing)。
2. 孤立型单元测试(Solitary Unit Testing) 如图,如果测试订单类的获取总价方法(Order.getTotalPrice())时,使用测试替身 (test doubles) 技术来替代用户类的优惠等级方法(User.reductionLevel())和商品类的商品单价方法(Goods.getUnitPrice())的效果。对象及其依赖项之间的交互和协作被测试替身代替,这种单元测试称之为孤立型单元测试(Solitary Unit Testing)。
另外,上述提到的测试替身是一种在测试中使用对象代替实际对象的技术,常用的技术如下。
桩代码(Stubs):当在对象上调用特定方法时,会对其进行硬编码(临时代码)的方式来代替真实代码提供固定响应。比如,某函数 X 的实现中调用了一个函数 Y,而 Y 不能调用,为了对函数 X 进行测试,就需要模拟一个函数 Y,那么函数 Y 的实现就是所谓的桩代码。
模拟代码(Mocks):模拟代码跟桩代码类似,它除了代替真实代码的能力之外,更强调是否使用了特定的参数调用了特定方法,因此,这种对象成为我们测试结果的基础。
根据被测单元是否与其交互者隔离,会产生以上两种单元测试类型,这两种类型的单元测试在微服务测试中都起着重要作用,它们用来解决不同的测试问题。