谈谈如何使用好单元测试这把武器

简介: 本文作者结合我们日常的工作,讨论如何使用好单元测试这把武器。

前言

如《Unit Testing》书里提到,


学习单元测试不应该仅仅停留在技术层面,比如你喜欢的测试框架,mocking 库等等,单元测试远远不止「写测试」这件事,你需要一直努力在单元测试中投入的时间回报最大化,尽量减少你在测试中投入的精力,并最大化测试提供的好处,实现这两点并不容易。

和我们在日常开发中遇到的问题一样,学会一门语言,掌握一种方法并不困难,困难的是把投入的时间回报最大化。unit test有很多基础知识和框架,在google上一搜就一大堆,最佳实践的方法论也非常多,本文不准备讨论这些问题,而是结合在我们日常的工作,讨论如何使用好单元测试这把武器。


单元测试的定义

什么是单元测试?来自百度


单元测试(unit testing),是指对软件中的最小可测试单元进行检查和验证。至于【单元】的含义,一般来说,要根据实际情况判定具体含义,如Java里单元指一个类等。

讲人话,单元测试就是为了验证一个类的准确性的测试。区别于集成测试和系统测试。他是前置的,由开发人员主导的最小规模的测试。


一些学者们经过统计,还绘制出了下图:


  • 85%的缺陷都在代码设计阶段产生;
  • 发现bug的阶段越靠后,耗费成本就越高,呈指数级别的增长。

由此看来,单测代码的编写对于交付质量以及人工耗费成本都有极其重要的影响


image.png

常见的误区

浪费时间,影响开发速度


不同项目的开发测试时间曲线不同,你要综合考虑你的代码的生命周期,你debug的能力,你平时花多少时间review有问题的代码。随着项目的进行,这些时间会递增,如果你想你所写的代码能够一直用下去,不让后来人吐槽这写的什么玩意,单元测试非常有必要。


测试应该是测试的工作


开发是代码的第一责任人,最熟悉代码的人,在设计阶段编辑单元测试,不但可以让你更自信的交付,还可以减少测试问题的产生。同时你自己的全栈能力也有所提升。


代码不是我写的,我不懂


我们经常抱怨老代码有坑难懂,或者是缺乏CR。其实在编写单元测试的过程中,也是CR和学习的一个过程,对于代码的主流程,边界,异常等有了深入的理解。同时也是自我审视代码规范、逻辑、设计的过程。我建议在重构中写单测,在写单测中重构,相辅相成。

如何写出好的单测

方法论上,有AIR 原则 ,像空气一样不会被感受到即 Automatic(自动化)、Independent(独立性)、Repeatable(可重复)。


个人的理解就是

1、自动运行,通过CI集成的方式,保证单测能够自动运行,通过assert保证单元测试的验证结果,而不是print输出。确保单元测试能够自动化运行,不需要人工介入测试。


2、单元测试必须独立,不能互相调用,也不能有依赖的顺序。每个测试用例之间包保证独立。


3、不可以受运行的环境、数据库、中间件等影响。在编写单测的时候,需要把外部的依赖mock掉。


从覆盖率的规范上来讲,不管是阿里内部还是业界,都有很多标准。


语句覆盖率达到70%;核心模块的语句覆盖率和分支覆盖率都要达到100%。 --- 《阿里巴巴Java开发手册》
单测覆盖度分级参考
Level1:正常流程可用,即一个函数在输入正确的参数时,会有正确的输出
Level2:异常流程可抛出逻辑异常,即输入参数有误时,不能抛出系统异常,而是用自己定义的逻辑异常通知上层调用代码其错误之处
Level3:极端情况和边界数据可用,对输入参数的边界情况也要单独测试,确保输出是正确有效的
Level4:所有分支、循环的逻辑走通,不能有任何流程是测试不到的
Level5:输出数据的所有字段验证,对有复杂数据结构的输出,确保每个字段都是正确的

从上面的摘录看,语句覆盖率和分支覆盖率都有数值上和方法论上的要求,那在实际工作中,实践情况如何呢?


笔者曾在一个季度,工作中提交的代码综合增量覆盖率几乎达到了100%。我可以谈谈我的经验和实践。


60%左右的单测覆盖率可以非常轻松达到,但达到95%以上的覆盖率,需要覆盖各种代码分支和异常情况等,甚至是配置和bean的初始化方法,所投入的时间非常巨大,但边际效应递减。我想测试toString, getter/setter这样的方法也没有意义。多少合适,我认为没有一个固定的标准。高代码覆盖率百分比不表示成功,也不意味着高代码质量。该舍弃测试的部分就大胆的ignore掉。

image.png

最佳实践

这个标题未免有些标题党。单元测试相关的书籍、ata文章,数不胜数,我的所谓“最佳实践”是在实际阿里工作中的一些自己踩过的坑,或者我个人认为一些重要的点,班门弄斧,如有错误,欢迎讨论。

1、隐藏的测试边界值


public ApiResponse<List<Long>> getInitingSolution() {
    List<Long> solutionIdList = new ArrayList<>();
    SolutionListParam solutionListParam = new SolutionListParam();
    solutionListParam.setSolutionType(SolutionType.GRAPH);
    solutionListParam.setStatus(SolutionStatus.INIT_PENDING);
    solutionListParam.setStartId(0L);
    solutionListParam.setPageSize(100);
    List<OperatingPlan> operatingPlanList =  operatingPlanMapper.queryOperatingPlanListByType(solutionListParam);
    for(; !CollectionUtils.isEmpty(operatingPlanList);){
        /*
            do something
            */
        solutionListParam.setStartId(operatingPlanList.get(operatingPlanList.size() - 1).getId());
        operatingPlanList =  operatingPlanMapper.queryOperatingPlanListByType(solutionListParam);
    }
    return ResponsePackUtils.packSuccessResult(solutionIdList);
}

上面这段代码,如何写单元测试?


很自然的,我们写单测的时候会mock掉数据库查询,并且查出信息。但是如果查询的内容超过100,由于for循环进入一次,无法通过jacoco的自动覆盖率发现。实际上没有覆盖这个边界case,只能通过开发者的习惯来处理这些边界情况。


如何处理这些隐藏的边界值,开发者不能依赖集成测试或者代码CR,必须要在自己写单元测试的时候考虑到这一情况,能避免后来维护的人掉坑。

2、不要在springboot测试中使用@Transactional以及操作真实数据库

单元测试的上下文应该是干净的,设计transactional的初衷是为了集成测试(如spring官网介绍):

image.png

虽然直接操作DB能更容易验证DAO层的正确性,但是也容易被线下数据库的脏数据污染,导致单测无法通过的问题。笔者以前遇到直连数据库的单测代码,经常改个5分钟代码,数据库里脏数据清一个小时。第二就是集成测试需要启动整个应用的容器,违背了提高效率的初衷。


如果实在要测DAO层的正确性,可以整合H2嵌入式数据库。这个网上教程非常多,不再赘述。

3、单测里时间相关的内容

笔者曾经在工作中遇到过一个极端case,一个CI平时都正常运行,有一次深夜发布, CI跑不过,后来经过第二天check才发现有前人在单测中取了当前时间,在业务逻辑中含有夜间逻辑(夜间消息不发),导致了CI无法通过。那么时间在单测中要如何处理呢?


在使用Mockito时,可以使用mock(Date.class)来模拟日期对象,然后使用when(date.getTime()).thenReturn(time)来设置日期对象的时间。


如果你使用了calendar.getInstance(),如何获取当前时间?Calendar.getInstance()是static方法,无法通过Mockito进行mock。需要引入powerMock,或者升级到mockito 4.x才能支持:


@RunWith(PowerMockRunner.class) 
@PrepareForTest({Calendar.class, ImpServiceTest.class})    
public class ImpServiceTest {

    @InjectMocks
    private ImpService impService = new ImpServiceImpl();

    @Before
    public void setup(){
        MockitoAnnotations.initMocks(this);

        Calendar now = Calendar.getInstance();
        now.set(2022, Calendar.JULY, 2 ,0,0,0);

        PowerMockito.mockStatic(Calendar.class);
        PowerMockito.when(Calendar.getInstance()).thenReturn(now);
    }
}


4、final类,static类等的单元测试

如第3点提到的calendar的例子,static类的mock需要mockito4.x的版本。否则就要引入powermock,powermock不兼容mockito3.x版本,不兼容mockito 4.x版本。由于老的应用引入了非常多的mockito3.x的版本,直接使用mockito4.x对final和static类进行mock需要排包。实践中看,JUnit、Mockito、Powermock三者之间的版本号有兼容性问题,可能会出现java.lang.NoSuchMethodError,需要根据实际的情况选择版本进行mock。


但是在新项目立项的时候,要确定好使用的mockito和junit版本,是否引入powermock等框架,确保环境稳定可用。老项目建议不要大规模改动mockito和powermock的版本,容易排包排到怀疑人生。

5、应用启动报 Can not load this fake sdk class 的异常

这是因为阿里的tair,metaq基于pandora容器的,fake-sdk默认是pandora模块类加载加载的。具体原理可以参考下图:

image.png

解决方案1,引入pandoraboot环境。


@RunWith(PandoraBootRunner.class)


这样其实减慢了单测的运行速度,是违背了高效性原理的。但是相比较运行整个容器,运行pandora容器的时间大概在10s左右,还是能够容许的。


那么有没有不让pandoraboot起来,纯mock的方法。我个人认为mock要比ut更优先 ,特别是有些外部依赖,经常迁移或者下线,可能改了1行代码,需要修1个小时测试用例。tair,lindorm等中间件也没有办法本地起环境进行mock,直接依赖外部资源非常不优雅。


解决方案2,直接mock


以tair为例:


@RunWith(PowerMockRunner.class)
@PrepareForTest({DataEntry.class})
public class MockTair {
    @Mock
    private DataEntry dataEntry;

    @Before
    public void hack() throws Exception {
        //solve it should be loaded by Pandora Container. Can not load this fake sdk class. please refer to http://gitlab.alibaba-inc.com/middleware-container/pandora-boot/wikis/faq for the solution
        PowerMockito.whenNew(DataEntry.class).withNoArguments().thenReturn(dataEntry);
    }
    
    @Test
    public void mock() throws Exception {
        String value = "value";
        PowerMockito.when(dataEntry.getValue()).thenReturn(value);
        DataEntry tairEntry = new DataEntry();
        //值相等
        Assert.assertEquals(value.equals(tairEntry.getValue()));
    }
}


6、metaq怎么写单测

MessageExt的mock方法参考5,但是单测中怎么运行一个MetaPushConsumer的bean,并调用listener方法。那就只能启动context的上下文。托管SpringRunner的方式。


@RunWith(PandoraBootRunner.class)
@DelegateTo(SpringRunner.class)
public class EventProcessorTest {

    @InjectMocks
    private EventProcessor eventProcessor;
    @Mock
    private DynamicService dynamicService;
    @Mock
    private MetaProducer dynamicEventProducer;

    @Test
    public void dynamicDelayConsumer() throws MQClientException, RemotingException, InterruptedException, MQBrokerException {
        //获取bean
        MetaPushConsumer metaPushConsumer = eventProcessor.dynamicEventConsumer();
        
        //获取Listener
        MessageListenerConcurrently messageListener = (MessageListenerConcurrently)metaPushConsumer.getMessageListener();
        List<MessageExt> list = new ArrayList<>();
        
        //这个需要依赖PandoraBootRunner
        MessageExt messageExt = new MessageExt();
        list.add(messageExt);
        Event event = new Event();
        event.setUserType(3);
        String text = JSON.toJSONString(event);
        messageExt.setBody(text.getBytes());
        messageExt.setMsgId(""+System.currentTimeMillis());
        
        //测试consumeMessage方法
        messageListener.consumeMessage(list, new ConsumeConcurrentlyContext(new MessageQueue()));
        doThrow(new RuntimeException()).when(dynamicService).triggerEventV2(any());
        messageListener.consumeMessage(list, new ConsumeConcurrentlyContext(new MessageQueue()));
        messageExt.setBody(null);
        messageListener.consumeMessage(list, new ConsumeConcurrentlyContext(new MessageQueue()));
    }
}


总结一下什么时候使用容器:


// 1. 使用PowerMockRunner
@RunWith(PowerMockRunner.class)

// 2.使用PandoraBootRunner, 启动pandora,使用tair,metaq等 
@RunWith(PandoraBootRunner.class)

// 3. springboot启动,加入context上下文,可以直接获取bean
@SpringBootTest(classes = {TestApplication.class})


7、尽量使用ioc

使用 IOC 可以解耦对象,使得测试更加方便。经常有这样的情况,在某个 service 中使用到某个工具类,这个工具类内的方法都是 static 的,这样的话,测试 service 的时候就会需要连着工具类一起测试了。


比如下面这段代码:


@Service
public class LoginServiceImpl implements LoginService{
    public Boolean login(String username, String password,String ip) {
        // 校验ip
        if (!IpUtil.verify(ip)) {
            return false;
        }
        /*
          other func
        */
        return true;
    }
}

通过IpUtil校验登录用户的ip信息,而如果我们这样使用,就需要测试 IpUtil的方法, 违背了隔离性的原则。测试login方法也需要加入更多组测试数据覆盖工具类代码,耦合度太高。


如果稍加修改:


@Service
public class LoginServiceImpl implements LoginService{
    public Boolean login(String username, String password,String ip) {
        // 校验ip
        if (!IpUtil.verify(ip)) {
            return false;
        }
        /*
          other func
        */
        return true;
    }
}

这样我们只需要单独测试IpUtil类和LoginServiceImpl类就行了。测试LoginServiceImpl的时候mockIpUtil就可以了,这样就隔离了IpUtil的实现。

8、不要为了覆盖率测没意义的代码

比如toString,比如getter,setter,都是机器生成的代码,单测没意义。如果是为了整体测试覆盖率的提高,那么请在CI中排掉这部分包:

image.png


9、如何测试void方法

  • 如果void方法内部造成了数据库的变更,比如insertPlan(Plan plan),并通过H2操作过数据库,那么可以验证数据库的条数变化等,校验void方法的正确性。
  • 如果void方法调用了函数,可以通过verify验证方法得到调用次数:

userService.updateName(1L,"qiushuo");
verify(mockedUserRepository, times(1)).updateName(1L,"qiushuo");
  • 如果void方法可能会造成抛出异常。

可以通过dothrow来 mock方法抛出的异常:


@Test(expected = InvalidParamException.class)
public void testUpdateNameThrowExceptionWhenIdNull() {
   doThrow(new InvalidParamException())
      .when(mockedUserRepository).updateName(null,anyString();
   userService.updateName(null,"qiushuo");
}

参考资料

1、https://scottming.github.io/2021/04/07/unit-testing/

2、https://docs.spring.io/spring-framework/docs/current/reference/html/testing.html#integration-testing

3、https://yuque.antfin-inc.com/fangqintao.fqt/pu2ycr/eabim6

4、https://yuque.antfin-inc.com/aone613114/en7p02/pdtwmb


作者| 胡春望(秋朔)
来源 | 阿里云开发者公众号

相关文章
|
Web App开发 编解码 监控
防御性设计和开发
“防御性编程(Defensive programming)是防御式设计的一种具体体现,它是为了保证,对程序的不可预见的使用,不会造成程序功能上的损坏。它可以被看作是为了减少或消除墨菲定律效力的想法。”
850 0
防御性设计和开发
|
3月前
|
测试技术 C# 开发者
“代码守护者:详解WPF开发中的单元测试策略与实践——从选择测试框架到编写模拟对象,全方位保障你的应用程序质量”
【8月更文挑战第31天】单元测试是确保软件质量的关键实践,尤其在复杂的WPF应用中更为重要。通过为每个小模块编写独立测试用例,可以验证代码的功能正确性并在早期发现错误。本文将介绍如何在WPF项目中引入单元测试,并通过具体示例演示其实施过程。首先选择合适的测试框架如NUnit或xUnit.net,并利用Moq模拟框架隔离外部依赖。接着,通过一个简单的WPF应用程序示例,展示如何模拟`IUserRepository`接口并验证`MainViewModel`加载用户数据的正确性。这有助于确保代码质量和未来的重构与扩展。
83 0
|
6月前
|
算法 测试技术 开发者
软件质量保证与测试知识点总结
【2月更文挑战第21天】软件质量保证与测试知识点总结
207 0
|
Dart 测试技术
带你读《深入浅出Dart》二十一、单元测试和集成测试
带你读《深入浅出Dart》二十一、单元测试和集成测试
|
Java 测试技术 Maven
单元测试运行原理探究
单元测试是软件开发过程中的重要一环,好的单测可以帮助我们更早的发现问题,为系统的稳定运行提供保障。单测还是很好的说明文档,我们往往看单测用例就能够了解到作者对类的设计意图。代码重构时也离不开单测,丰富的单测用例会使我们重构代码时信心满满。
单元测试运行原理探究
|
消息中间件 NoSQL Java
谈谈如何使用好单元测试这把武器
本文作者结合我们日常的工作,讨论如何使用好单元测试这把武器。
|
测试技术
测试思想 单元测试用例基础设计思想总结
测试思想 单元测试用例基础设计思想总结
94 0
|
网络协议 测试技术 Go
单元测试细节说明 | 学习笔记
快速学习单元测试细节说明
|
网络协议 测试技术 Go
单元测试的引出 | 学习笔记
快速学习单元测试的引出
|
测试技术
软件测试面试题:手工测试与自动测试有哪些区别?
软件测试面试题:手工测试与自动测试有哪些区别?
116 0
下一篇
无影云桌面