卓越工程之单元测试在行权鉴权中的实践

简介: 在去年的时候就读过《重构:改善既有代码的设计》这本在代码重构领域里的经典,当时在读的时候就苦于有这么两点导致只停留在了“读”上面,而缺少实践。

作者 | 庆羽(羽哲)

来源 | 阿里开发者公众号



前言


在去年的时候就读过《重构:改善既有代码的设计》这本在代码重构领域里的经典,当时在读的时候就苦于有这么两点导致只停留在了“读”上面,而缺少实践。



1.全书内容比较枯燥乏味,虽然有部分代码示例,但是语言并不生动,让人坚持读下去就很难。

2.书中强调,每做一次代码的重构,即使修改很小的部分,也应该对修改进行测试,所以在看到书中举例的各种重构和重构后的不断测试时,就对测试和重构打起了退堂鼓


因为对代码的测试缺少整体的认知,对单元测试也一直停留在简单的print层面,直到在这几天通过一个阅读打卡活动,系统性的学习了大量关于单元测试的理论、实践知识和在代码重构中的帮助,重新让我回忆起《重构》书中所提到的知识点,一直跃跃欲试,所以也想尝试将单元测试实际应用在自己写的业务代码中,为自己的代码“保驾护航”,同时在代码中有单测,在重构的过程中单测也会让自己不慌张,修改代码后直接执行一下单测就可以对修改后的准确性进行验证。这篇文章着重在“实践”上,是对Java编程技巧之单元测试用例编写流程这篇文章的实际应用,并没有高深的理论和技术。



流程


包括单元测试在内的所有测试都应该对所需要测试的流程有比较清晰的认识才能保证测试的用例不被遗漏,保证测试质量,因此在撰写单元测试前,首先需要对所测试部分代码的流程进行梳理。


640.png



1.用户发起查询时,首先判断用户传入的参数中是否包含行权验证的字段,如果不包含则直接抛出异常,提示鉴权失败;


2.在鉴权中,因为行权可能会由多个字段组合鉴权,因此需要对全部鉴权字段进行遍历。在鉴权时,还会有匹配字段,包含:

  • 等值匹配(=)
  • 前缀匹配(like xxx%)
  • 后缀匹配(like %xxx)
  • 模糊匹配(like %xxx%)


四种形式,当用户输入参数与匹配字段不相符时,记作鉴权失败。

3.当用户没有输入参数中的权限时,记作鉴权失败。

4.在多个鉴权字段进行组合时,还会存在两种组合逻辑:and(所有字段均需要有权限才能访问)和 or(任意字段有权限即可访问),所以还会结合组合逻辑进行综合权限判定。



测试边界


在明确了代码的流程后,就需要对测试边界进行明确,测试应该着重对边界情况进行测试,因为清晰的单元测试边界划分有利于构建更加稳定的系统核心代码,因为我们在推进测试边界的过程中会不断地将副作用从核心代码中剥离出去,最终会得到一个完整且可测试的核心,而我们的核心代码就是处于测试边界内的。下图将所有的情况做了枚举,作为单元测试的用例。

image.png



撰写单元测试


引入依赖

<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-core</artifactId>
    <version>${powermock.version}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-api-mockito2</artifactId>
    <version>${powermock.version}</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.powermock</groupId>
    <artifactId>powermock-module-junit4</artifactId>
    <version>${powermock.version}</version>
    <scope>test</scope>
</dependency>


其中,powermock.version为2.0.9,为当前的最新版本,可根据实际情况修改。在PowerMock包中,已经包含了对应的Mockito和JUnit包,所以无需单独引入Mockito和JUnit包。


模拟方法


1.首先是需要对外部依赖和进行测试的类进行模拟和注入:

   // 需要模拟的外部依赖
    @Mock
    private ArkDataSetReadService arkDataSetReadService;
    // 需要进行测试的类
    @InjectMocks
    private ComponentJobExecuteService componentJobExecuteService;


2.之后就是对依赖的方法进行模拟:

Response<RowPermissionQueryResponseDto> response = JSON.parseObject(permissionData, Response.class);
Mockito.doReturn(response).when(arkDataSetReadService).getUserRowPermissions(911L, 1741141);


通过文本的方式构造模拟的返回值。

通过Mockito.doReturn() 方法模拟调用时的返回值。


3.最后就是对所测试的方法进行测试:

Map<String, Pair<String, List<String>>> filterParams = new HashMap<>();
Whitebox.invokeMethod(componentJobExecuteService, "checkRowPermission", 911L, filterParams)


完整的测试代码:

@Test(expected = AuthException.class)
    public void testRowPermission() throws Exception {
        ContextInfo contextInfo = new ContextInfo();
        contextInfo.setBucId(1741141);
        ContextInfoHolder.setContextInfo(contextInfo);
        Response<RowPermissionQueryResponseDto> response = JSON.parseObject(permissionData, Response.class);
        Mockito.doReturn(response).when(arkDataSetReadService).getUserRowPermissions(911L, 1741141);
        Map<String, Pair<String, List<String>>> filterParams = new HashMap<>();
        Whitebox.invokeMethod(componentJobExecuteService, "checkRowPermission", 911L, filterParams);
    }


因为在没有权限的时候会直接抛出 AuthException,所以通过@Test(expected = AuthException.class) 进行验证。


到此,行权验证的单元测试框架就初步搭建完成,接下来就是根据前面梳理的单元测试用例的边界构建不同的参数进行验证。



总结


在实际撰写单元测试时,由于对工具的不熟悉担心写起来比较麻烦,所以一直没进行尝试,但是在实际操作的时候发现,在写单元测试的时候,其实也是对整个代码进行梳理的过程,是对自己写代码时思路的复盘和总结,单测不只是能验证代码执行的准确性,还能验证在写代码时的逻辑是否正确、能否满足业务的实际需求。


有了单测打底,接下来即使需要对这部分代码进行重构、迭代,也能做到心中有数,只需要在重构完成后执行下单测就可以轻松验证代码的准确性。


希望能够通过这次实践,能够让自己在写单测的路上坚持下去。


相关文章
|
1天前
|
敏捷开发 Devops jenkins
深入理解与实践:持续集成在软件测试中的应用
【5月更文挑战第20天】 随着敏捷开发和DevOps文化的普及,持续集成(Continuous Integration, CI)已成为软件开发周期中不可或缺的一环。本文将探讨CI在软件测试中的关键作用,包括其如何提高测试效率、减少集成问题以及促进团队协作。通过分析持续集成的工作流程和工具使用,我们将展示如何在现代软件工程实践中有效地整合CI策略,以确保代码质量和项目稳定性。
|
4天前
|
敏捷开发 运维 监控
深入探索软件测试中的持续集成与持续部署(CI/CD)实践
【5月更文挑战第17天】 在现代软件开发过程中,"持续集成"(Continuous Integration, CI)和"持续部署"(Continuous Deployment, CD)已经成为提高开发效率、确保代码质量和加速产品上市速度的关键策略。本文将深入探讨CI/CD在软件测试中的应用,包括它们的定义、目的、实施策略以及面临的挑战。通过对自动化测试、版本控制、构建流程和反馈循环的详细分析,我们将揭示如何利用CI/CD实践来优化测试流程,减少错误,并确保高质量的软件交付。
|
7天前
|
设计模式 敏捷开发 监控
深入理解自动化测试框架的设计原则与实践
【5月更文挑战第15天】在软件工程的领域里,自动化测试已成为提高软件开发效率、保障产品质量的重要手段。本文将深入探讨自动化测试框架的设计原则及其在实际项目中的应用实践。通过分析设计模式、模块化、可扩展性等关键因素,揭示构建高效、可靠自动化测试框架的策略和方法。同时,结合实际案例,展示如何在多变的测试需求中保持测试框架的稳定性和灵活性。
|
7天前
|
敏捷开发 监控 Devops
深入探索软件测试中的持续集成与持续部署(CI/CD)实践
【5月更文挑战第13天】 在现代软件开发的快节奏和复杂性中,持续集成(Continuous Integration,CI)与持续部署(Continuous Deployment,CD)成为确保软件质量和加速交付的关键策略。本文将深入探讨CI/CD在软件测试中的应用,解析其核心概念、流程以及面临的挑战,并分享实际案例分析以揭示如何在不断变化的开发环境中维持高效和可靠的软件发布周期。
|
7天前
|
机器学习/深度学习 敏捷开发 监控
深入探索软件测试中的持续集成与持续部署(CI/CD)实践
【5月更文挑战第10天】 在现代软件开发周期中,"持续集成"(CI)与"持续部署"(CD)是提升效率、确保质量的重要环节。本文将详细探讨CI/CD在软件测试中的应用,包括其基本概念、实施策略、工具应用及面临的挑战。不同于一般性概述,本文将重点分析如何优化测试流程以适应CI/CD环境,并提出针对性的改进措施。通过实际案例分析,揭示成功实施CI/CD的最佳实践,并讨论如何在不断变化的技术环境中保持测试策略的前瞻性和灵活性。
|
7天前
|
算法 测试技术 开发者
测试驱动开发(TDD)实战:从理论到实践
【5月更文挑战第8天】TDD实战指南:先测试后开发,确保代码质量与可维护性。核心思想是编写测试用例→实现代码→验证→重构。优点包括提高代码质量、促进设计思考和增强可测试性。实战步骤包括编写独立、明确的测试用例,遵循最小可用原则编写代码,运行测试并分析失败原因,以及在验证通过后进行代码重构与优化。通过TDD,开发者能提升编程技能和项目成功率。
|
7天前
|
Java 测试技术 Maven
5个编写技巧,有效提高单元测试实践
本文作者详细讲解了关于单元测试的相关知识,做好单元测试能有效地保障代码质量,本文将手把手教你学会应用单元测试并附有案例、测试插件。
|
7天前
|
Java 测试技术 开发者
卓越工程之单元测试在行权鉴权中的实践
这篇文章着重在“实践”上,是对Java编程技巧之单元测试用例编写流程这篇文章的实际应用,并没有高深的理论和技术。
54 10
|
7天前
|
Web App开发 JSON 前端开发
我理解的测试开发与实践总结——新人篇
本文以作者的视角,讲述了测试与开发、产品之间的关系,如何做好一个测试以及做好一个测试应当具有的素质与技能。
|
7天前
|
敏捷开发 测试技术 持续交付
深入理解自动化测试:框架与实践
【5月更文挑战第5天】 在现代软件开发周期中,自动化测试已成为确保产品质量和加速交付过程的关键环节。本文将深入探讨自动化测试的核心概念、框架选择以及实际实施过程中的最佳实践。通过分析各种自动化测试工具和技术的优缺点,我们旨在为读者提供一种系统化的方法来构建和维护有效的自动化测试环境。

热门文章

最新文章