SpringBoot2.2
[TOC]
45、web实验-抽取公共页面
公共页面
/templates/common.html
<!DOCTYPE html>
<html lang="en" xmlns:th="http://www.thymeleaf.org"><!--注意要添加xmlns:th才能添加thymeleaf的标签-->
<head th:fragment="commonheader">
<!--common-->
<link href="css/style.css" th:href="@{/css/style.css}" rel="stylesheet">
<link href="css/style-responsive.css" th:href="@{/css/style-responsive.css}" rel="stylesheet">
...
</head>
<body>
<!-- left side start-->
<div id="leftmenu" class="left-side sticky-left-side">
...
<div class="left-side-inner">
...
<!--sidebar nav start-->
<ul class="nav nav-pills nav-stacked custom-nav">
<li><a th:href="@{/main.html}"><i class="fa fa-home"></i> <span>Dashboard</span></a></li>
...
<li class="menu-list nav-active"><a href="#"><i class="fa fa-th-list"></i> <span>Data Tables</span></a>
<ul class="sub-menu-list">
<li><a th:href="@{/basic_table}"> Basic Table</a></li>
<li><a th:href="@{/dynamic_table}"> Advanced Table</a></li>
<li><a th:href="@{/responsive_table}"> Responsive Table</a></li>
<li><a th:href="@{/editable_table}"> Edit Table</a></li>
</ul>
</li>
...
</ul>
<!--sidebar nav end-->
</div>
</div>
<!-- left side end-->
<!-- header section start-->
<div th:fragment="headermenu" class="header-section">
<!--toggle button start-->
<a class="toggle-btn"><i class="fa fa-bars"></i></a>
<!--toggle button end-->
...
</div>
<!-- header section end-->
<div id="commonscript">
<!-- Placed js at the end of the document so the pages load faster -->
<script th:src="@{/js/jquery-1.10.2.min.js}"></script>
<script th:src="@{/js/jquery-ui-1.9.2.custom.min.js}"></script>
<script th:src="@{/js/jquery-migrate-1.2.1.min.js}"></script>
<script th:src="@{/js/bootstrap.min.js}"></script>
<script th:src="@{/js/modernizr.min.js}"></script>
<script th:src="@{/js/jquery.nicescroll.js}"></script>
<!--common scripts for all pages-->
<script th:src="@{/js/scripts.js}"></script>
</div>
</body>
</html>/templates/table/basic_table.html
Difference between th:insert and th:replace (and th:include)
46、web实验-遍历数据与页面bug修改
控制层代码:
页面代码:
47、视图解析-【源码分析】-视图解析器与视图
视图解析原理流程:
目标方法处理的过程中(阅读
DispatcherServlet源码),所有数据都会被放在ModelAndViewContainer里面,其中包括数据和视图地址。方法的参数是一个自定义类型对象(从请求参数中确定的),把他重新放在
ModelAndViewContainer。任何目标方法执行完成以后都会返回
ModelAndView(数据和视图地址)。处理派发结果(页面改如何响应)
进行页面渲染逻辑
根据方法的
String返回值得到View对象【定义了页面的渲染逻辑】所有的视图解析器尝试是否能根据当前返回值得到
View对象得到了
redirect:/main.html --> Thymeleaf new RedirectView()。ContentNegotiationViewResolver里面包含了下面所有的视图解析器,内部还是利用下面所有视图解析器得到视图对象。view.render(mv.getModelInternal(), request, response);视图对象调用自定义的render进行页面渲染工作。RedirectView如何渲染【重定向到一个页面】获取目标url地址
response.sendRedirect(encodedURL);
视图解析: - 返回值以 forward: 开始: new InternalResourceView(forwardUrl); --> 转发request.getRequestDispatcher(path).forward(request, response); - 返回值以 redirect: 开始: new RedirectView() --> render就是重定向 - 返回值是普通字符串:new ThymeleafView()—>
阅读源码:最好自己在IDE,打断点,且Debug模式运行实例,这样比较没那么沉闷。
48、拦截器-登录检查与静态资源放行
编写一个拦截器实现
HandlerInterceptor接口拦截器注册到容器中(实现
WebMvcConfigurer的addInterceptors())指定拦截规则(注意,如果是拦截所有,静态资源也会被拦截】
编写一个实现HandlerInterceptor接口的拦截器:
拦截器注册到容器中 && 指定拦截规则:
49、拦截器-【源码分析】-拦截器的执行时机和原理
根据当前请求,找到
HandlerExecutionChain(可以处理请求的handler以及handler的所有 拦截器)先来顺序执行 所有拦截器的
方法。
如果当前拦截器
preHandle()返回为true。则执行下一个拦截器的preHandle()如果当前拦截器返回为
false。直接倒序执行所有已经执行了的拦截器的afterCompletion();。
如果任何一个拦截器返回
false,直接跳出不执行目标方法。所有拦截器都返回
true,才执行目标方法。倒序执行所有拦截器的
postHandle()方法。前面的步骤有任何异常都会直接倒序触发
afterCompletion()。页面成功渲染完成以后,也会倒序触发
afterCompletion()。

DispatcherServlet中涉及到HandlerInterceptor的地方:
50、文件上传-单文件与多文件上传的使用
页面代码
/static/form/form_layouts.html
控制层代码
文件上传相关的配置类:
org.springframework.boot.autoconfigure.web.servlet.MultipartAutoConfigurationorg.springframework.boot.autoconfigure.web.servlet.MultipartProperties
文件大小相关配置项:
51、文件上传-【源码流程】文件上传参数解析器
文件上传相关的自动配置类MultipartAutoConfiguration有创建文件上传参数解析器StandardServletMultipartResolver。
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());跳到以下的类
this.argumentResolvers其中主角类RequestPartMethodArgumentResolver用来生成
52、错误处理-SpringBoot默认错误处理机制
Spring Boot官方文档 - Error Handling
默认规则:
默认情况下,Spring Boot提供
/error处理所有错误的映射机器客户端,它将生成JSON响应,其中包含错误,HTTP状态和异常消息的详细信息。对于浏览器客户端,响应一个“ whitelabel”错误视图,以HTML格式呈现相同的数据
要对其进行自定义,添加
View解析为error要完全替换默认行为,可以实现
ErrorController并注册该类型的Bean定义,或添加ErrorAttributes类型的组件以使用现有机制但替换其内容。/templates/error/下的4xx,5xx页面会被自动解析
53、错误处理-【源码分析】底层组件功能分析
ErrorMvcAutoConfiguration自动配置异常处理规则容器中的组件:类型:
DefaultErrorAttributes-> id:errorAttributesDefaultErrorAttributes:定义错误页面中可以包含数据(异常明细,堆栈信息等)。
容器中的组件:类型:
BasicErrorController--> id:basicErrorController(json+白页 适配响应)处理默认
/error路径的请求,页面响应
容器中有组件
View->id是error;(响应默认错误页)容器中放组件
BeanNameViewResolver(视图解析器);按照返回的视图名作为组件的id去容器中找View对象。
容器中的组件:类型:
DefaultErrorViewResolver-> id:conventionErrorViewResolver如果发生异常错误,会以HTTP的状态码 作为视图页地址(viewName),找到真正的页面
(主要作用)。
error/404、5xx.html
如果想要返回页面,就会找error视图(
StaticView默认是一个白页)。
54、错误处理-【源码流程】异常处理流程
譬如写一个会抛出异常的控制层:
当浏览器发出/hello请求,DispatcherServlet的doDispatch()的mv = ha.handle(processedRequest, response, mappedHandler.getHandler());将会抛出ArithmeticException。
系统自带的异常解析器:

DefaultErrorAttributes先来处理异常,它主要功能把异常信息保存到request域,并且返回null。
默认没有任何解析器(上图的
HandlerExceptionResolverComposite)能处理异常,所以最后异常会被抛出。最终底层就会转发
/error请求。会被底层的BasicErrorController处理。
55、==错误处理-【源码流程】几种异常处理原理==
自定义错误页
error/404.html error/5xx.html;有精确的错误状态码页面就匹配精确,没有就找 4xx.html;如果都没有就触发白页
@ControllerAdvice+@ExceptionHandler处理全局异常;底层是ExceptionHandlerExceptionResolver支持的
@ResponseStatus+自定义异常 ;底层是ResponseStatusExceptionResolver,把responseStatus注解的信息底层调用response.sendError(statusCode, resolvedReason),tomcat发送的/error
Spring自家异常如
org.springframework.web.bind.MissingServletRequestParameterException,DefaultHandlerExceptionResolver处理Spring自家异常。response.sendError(HttpServletResponse.SC_BAD_REQUEST/*400*/, ex.getMessage());
自定义实现
HandlerExceptionResolver处理异常;可以作为默认的全局异常处理规则
实现自定义处理异常
response.sendError(),error请求就会转给controller。你的异常没有任何人能处理,tomcat底层调用
response.sendError(),error请求就会转给controller。basicErrorController要去的页面地址是ErrorViewResolver。
56、原生组件注入-原生注解与Spring方式注入
官方文档 - Servlets, Filters, and listeners
使用原生的注解
最后还要在主启动类添加注解@ServletComponentScan
Spring方式注入
57、原生组件注入-【源码分析】DispatcherServlet注入原理
org.springframework.boot.autoconfigure.web.servlet.DispatcherServletAutoConfiguration配置类
DispatcherServlet默认映射的是 / 路径,可以通过在配置文件修改spring.mvc.servlet.path=/mvc。
58、嵌入式Servlet容器-【源码分析】切换web服务器与定制化
默认支持的WebServer
Tomcat,Jetty, orUndertow。ServletWebServerApplicationContext容器启动寻找ServletWebServerFactory并引导创建服务器。
原理
SpringBoot应用启动发现当前是Web应用,web场景包-导入tomcat。
web应用会创建一个web版的IOC容器
ServletWebServerApplicationContext。ServletWebServerApplicationContext启动的时候寻找ServletWebServerFactory(Servlet 的web服务器工厂——>Servlet 的web服务器)。SpringBoot底层默认有很多的WebServer工厂(
内创建Bean),如:
TomcatServletWebServerFactoryJettyServletWebServerFactoryUndertowServletWebServerFactory
底层直接会有一个自动配置类
ServletWebServerFactoryAutoConfiguration。ServletWebServerFactoryAutoConfiguration导入了ServletWebServerFactoryConfiguration(配置类)。ServletWebServerFactoryConfiguration根据动态判断系统中到底导入了那个Web服务器的包。(默认是web-starter导入tomcat包),容器中就有TomcatServletWebServerFactoryTomcatServletWebServerFactory创建出Tomcat服务器并启动;TomcatWebServer的构造器拥有初始化方法initialize——this.tomcat.start();内嵌服务器,与以前手动把启动服务器相比,改成现在使用代码启动(tomcat核心jar包存在)。
Spring Boot默认使用Tomcat服务器,若需更改其他服务器,则修改工程pom.xml:
定制Servlet容器
实现
WebServerFactoryCustomizer<ConfigurableServletWebServerFactory>把配置文件的值和
ServletWebServerFactory进行绑定
修改配置文件
server.xxx直接自定义
ConfigurableServletWebServerFactory
xxxxxCustomizer:定制化器,可以改变xxxx的默认规则
59、定制化原理-SpringBoot定制化组件的几种方式(小结)
定制化的常见方式
修改配置文件
xxxxxCustomizer编写自定义的配置类
xxxConfiguration+@Bean替换、增加容器中默认组件,视图解析器Web应用 编写一个配置类实现
WebMvcConfigurer即可定制化web功能 +@Bean给容器中再扩展一些组件
@EnableWebMvcWebMvcConfigurer—
@Bean可以全面接管SpringMVC,所有规则全部自己重新配置; 实现定制和扩展功能(
高级功能,初学者退避三舍
)。
原理:
WebMvcAutoConfiguration默认的SpringMVC的自动配置功能类,如静态资源、欢迎页等。一旦使用
@EnableWebMvc,会@Import(DelegatingWebMvcConfiguration.class)。DelegatingWebMvcConfiguration的作用,只保证SpringMVC最基本的使用
把所有系统中的
WebMvcConfigurer拿过来,所有功能的定制都是这些WebMvcConfigurer合起来一起生效。自动配置了一些非常底层的组件,如
RequestMappingHandlerMapping,这些组件依赖的组件都是从容器中获取如。public class DelegatingWebMvcConfiguration extends WebMvcConfigurationSupport。
WebMvcAutoConfiguration里面的配置要能生效必须@ConditionalOnMissingBean(WebMvcConfigurationSupport.class)。@EnableWebMvc 导致了WebMvcAutoConfiguration 没有生效。
原理分析套路
场景starter - xxxxAutoConfiguration - 导入xxx组件 - 绑定xxxProperties - 绑定配置文件项。
60、数据访问-数据库场景的自动配置分析与整合测试
导入JDBC场景
接着导入数据库驱动包(MySQL为例)。
相关数据源配置类
DataSourceAutoConfiguration: 数据源的自动配置。修改数据源相关的配置:
spring.datasource。数据库连接池的配置,是自己容器中没有DataSource才自动配置的。
底层配置好的连接池是:
HikariDataSource。
DataSourceTransactionManagerAutoConfiguration: 事务管理器的自动配置。JdbcTemplateAutoConfiguration:JdbcTemplate的自动配置,可以来对数据库进行CRUD。可以修改前缀为
spring.jdbc的配置项来修改JdbcTemplate。@Bean @Primary JdbcTemplate:Spring容器中有这个JdbcTemplate组件,使用@Autowired。
JndiDataSourceAutoConfiguration: JNDI的自动配置。XADataSourceAutoConfiguration: 分布式事务相关的。
修改配置项
单元测试数据源
61、数据访问-自定义方式整合druid数据源
Druid是什么?
它是数据库连接池,它能够提供强大的监控和扩展功能。
Spring Boot整合第三方技术的两种方式:
自定义
找starter场景
自定义方式
添加依赖:
配置Druid数据源:
配置Druid的监控页功能:
Druid内置提供了一个
StatViewServlet用于展示Druid的统计信息。官方文档 - 配置_StatViewServlet配置。这个StatViewServlet的用途包括:提供监控信息展示的html页面
提供监控信息的JSON API
Druid内置提供一个
StatFilter,用于统计监控信息。官方文档 - 配置_StatFilterWebStatFilter用于采集web-jdbc关联监控的数据,如SQL监控、URI监控。官方文档 - 配置_配置WebStatFilterDruid提供了
WallFilter,它是基于SQL语义分析来实现防御SQL注入攻击的。官方文档 - 配置 wallfilter
62、数据访问-druid数据源starter整合方式
官方文档 - Druid Spring Boot Starter
引入依赖:
分析自动配置:
扩展配置项
spring.datasource.druid自动配置类
DruidDataSourceAutoConfigureDruidSpringAopConfiguration.class, 监控SpringBean的;配置项:spring.datasource.druid.aop-patternsDruidStatViewServletConfiguration.class, 监控页的配置。spring.datasource.druid.stat-view-servlet默认开启。DruidWebStatFilterConfiguration.class,web监控配置。spring.datasource.druid.web-stat-filter默认开启。DruidFilterConfiguration.class所有Druid的filter的配置:
配置示例:
63、数据访问-整合MyBatis-配置版
starter的命名方式:
SpringBoot官方的Starter:
spring-boot-starter-*第三方的:
*-spring-boot-starter
引入依赖:
配置模式:
全局配置文件
SqlSessionFactory:自动配置好了SqlSession:自动配置了SqlSessionTemplate组合了SqlSession@Import(AutoConfiguredMapperScannerRegistrar.class)Mapper: 只要我们写的操作MyBatis的接口标准了@Mapper就会被自动扫描进来
配置文件:
mybatis-config.xml:
Mapper接口:
POJO:
DB:
Controller and Service:
配置private Configuration configuration; 也就是配置mybatis.configuration相关的,就是相当于改mybatis全局配置文件中的值。(也就是说配置了mybatis.configuration,就不需配置mybatis全局配置文件了)
小结
导入MyBatis官方Starter。
编写Mapper接口,需
@Mapper注解。编写SQL映射文件并绑定Mapper接口。
在
application.yaml中指定Mapper配置文件的所处位置,以及指定全局配置文件的信息 (建议:配置在mybatis.configuration)。
64、数据访问-整合MyBatis-注解配置混合版
你可以通过Spring Initializr添加MyBatis的Starer。
注解与配置混合搭配,干活不累:
简单DAO方法就写在注解上。复杂的就写在配置文件里。
使用
@MapperScan("com.lun.boot.mapper")简化,Mapper接口就可以不用标注@Mapper注解。
65、数据访问-整合MyBatisPlus操作数据库
MyBatisPlus是什么
MyBatis-Plus(简称 MP)是一个 MyBatis的增强工具,在 MyBatis 的基础上只做增强不做改变,为简化开发、提高效率而生。
添加依赖:
MybatisPlusAutoConfiguration配置类,MybatisPlusProperties配置项绑定。SqlSessionFactory自动配置好,底层是容器中默认的数据源。mapperLocations自动配置好的,有默认值classpath*:/mapper/**/*.xml,这表示任意包的类路径下的所有mapper文件夹下任意路径下的所有xml都是sql映射文件。 建议以后sql映射文件放在 mapper下。容器中也自动配置好了
SqlSessionTemplate。@Mapper标注的接口也会被自动扫描,建议直接@MapperScan("com.lun.boot.mapper")批量扫描。MyBatisPlus优点之一:只需要我们的Mapper继承MyBatisPlus的
BaseMapper就可以拥有CRUD能力,减轻开发工作。
66、数据访问-CRUD实验-数据列表展示
使用MyBatis Plus提供的IService,ServiceImpl,减轻Service层开发工作。
与下一节联合在一起
67、数据访问-CRUD实验-分页数据展示
与下一节联合在一起
68、数据访问-CRUD实验-删除用户完成
添加分页插件:
#numbers表示methods for formatting numeric objects.link
69、数据访问-准备阿里云Redis环境
添加依赖:
RedisAutoConfiguration自动配置类,RedisProperties 属性类 --> spring.redis.xxx是对redis的配置。连接工厂
LettuceConnectionConfiguration、JedisConnectionConfiguration是准备好的。自动注入了
RedisTemplate<Object, Object>,xxxTemplate。自动注入了
StringRedisTemplate,key,value都是String底层只要我们使用
StringRedisTemplate、RedisTemplate就可以操作Redis。
外网Redis环境搭建:
阿里云按量付费Redis,其中选择经典网络。
申请Redis的公网连接地址。
修改白名单,允许
0.0.0.0/0访问。
70、数据访问-Redis操作与统计小实验
相关Redis配置:
测试Redis连接:
Redis Desktop Manager:可视化Redis管理软件。
URL统计拦截器:
注册URL统计拦截器:
Filter、Interceptor 几乎拥有相同的功能?
Filter是Servlet定义的原生组件,它的好处是脱离Spring应用也能使用。
Interceptor是Spring定义的接口,可以使用Spring的自动装配等功能。
调用Redis内的统计数据:
71、单元测试-JUnit5简介
Spring Boot 2.2.0 版本开始引入 JUnit 5 作为单元测试默认库
作为最新版本的JUnit框架,JUnit5与之前版本的JUnit框架有很大的不同。由三个不同子项目的几个不同模块组成。
JUnit 5 = JUnit Platform + JUnit Jupiter + JUnit Vintage
JUnit Platform: Junit Platform是在JVM上启动测试框架的基础,不仅支持Junit自制的测试引擎,其他测试引擎也都可以接入。
JUnit Jupiter: JUnit Jupiter提供了JUnit5的新的编程模型,是JUnit5新特性的核心。内部包含了一个测试引擎,用于在Junit Platform上运行。
JUnit Vintage: 由于JUint已经发展多年,为了照顾老的项目,JUnit Vintage提供了兼容JUnit4.x,JUnit3.x的测试引擎。
注意:
SpringBoot 2.4 以上版本移除了默认对 Vintage 的依赖。如果需要兼容JUnit4需要自行引入(不能使用JUnit4的功能 @Test)
JUnit 5’s Vintage已经从
spring-boot-starter-test从移除。如果需要继续兼容Junit4需要自行引入Vintage依赖:
使用添加JUnit 5,添加对应的starter:
Spring的JUnit 5的基本单元测试模板(Spring的JUnit4的是
@SpringBootTest+@RunWith(SpringRunner.class)):
Jupiter
英 [ˈdʒuːpɪtə®] 美 [ˈdʒuːpɪtər]
n. 木星(太阳系中最大的行星)
vintage
英 [ˈvɪntɪdʒ] 美 [ˈvɪntɪdʒ]
n. 特定年份(或地方)酿制的酒;酿造年份;采摘葡萄酿酒的期间(或季节);葡萄收获期(或季节)
adj. (指葡萄酒)优质的,上等的,佳酿的;古色古香的(指1917–1930年间制造,车型和品味受人青睐的);(过去某个时期)典型的,优质的;(某人的)最佳作品的
72、单元测试-常用测试注解
@Test:表示方法是测试方法。但是与JUnit4的@Test不同,他的职责非常单一不能声明任何属性,拓展的测试将会由Jupiter提供额外测试
@ParameterizedTest:表示方法是参数化测试。
@RepeatedTest:表示方法可重复执行。
@DisplayName:为测试类或者测试方法设置展示名称。
@BeforeEach:表示在每个单元测试之前执行。
@AfterEach:表示在每个单元测试之后执行。
@BeforeAll:表示在所有单元测试之前执行。
@AfterAll:表示在所有单元测试之后执行。
@Tag:表示单元测试类别,类似于JUnit4中的@Categories。
@Disabled:表示测试类或测试方法不执行,类似于JUnit4中的@Ignore。
@Timeout:表示测试方法运行如果超过了指定时间将会返回错误。
@ExtendWith:为测试类或测试方法提供扩展类引用。
73、单元测试-断言机制
断言Assertion是测试方法中的核心部分,用来对测试需要满足的条件进行验证。这些断言方法都是org.junit.jupiter.api.Assertions的静态方法。检查业务逻辑返回的数据是否合理。所有的测试运行结束以后,会有一个详细的测试报告。
JUnit 5 内置的断言可以分成如下几个类别:
简单断言
用来对单个值进行简单的验证。如:
assertEquals
判断两个对象或两个原始类型是否相等
assertNotEquals
判断两个对象或两个原始类型是否不相等
assertSame
判断两个对象引用是否指向同一个对象
assertNotSame
判断两个对象引用是否指向不同的对象
assertTrue
判断给定的布尔值是否为 true
assertFalse
判断给定的布尔值是否为 false
assertNull
判断给定的对象引用是否为 null
assertNotNull
判断给定的对象引用是否不为 null
数组断言
通过 assertArrayEquals 方法来判断两个对象或原始类型的数组是否相等。
组合断言
assertAll()方法接受多个 org.junit.jupiter.api.Executable 函数式接口的实例作为要验证的断言,可以通过 lambda 表达式很容易的提供这些断言。
异常断言
在JUnit4时期,想要测试方法的异常情况时,需要用@Rule注解的ExpectedException变量还是比较麻烦的。而JUnit5提供了一种新的断言方式Assertions.assertThrows(),配合函数式编程就可以进行使用。
超时断言
JUnit5还提供了Assertions.assertTimeout()为测试方法设置了超时时间。
快速失败
通过 fail 方法直接使得测试失败。
74、单元测试-前置条件
Unit 5 中的前置条件(assumptions【假设】)类似于断言,不同之处在于不满足的断言assertions会使得测试方法失败,而不满足的前置条件只会使得测试方法的执行终止。
前置条件可以看成是测试方法执行的前提,当该前提不满足时,就没有继续执行的必要。
assumeTrue 和 assumFalse 确保给定的条件为 true 或 false,不满足条件会使得测试执行终止。
assumingThat 的参数是表示条件的布尔值和对应的 Executable 接口的实现对象。只有条件满足时,Executable 对象才会被执行;当条件不满足时,测试执行并不会终止。
75、单元测试-嵌套测试
JUnit 5 可以通过 Java 中的内部类和@Nested 注解实现嵌套测试,从而可以更好的把相关的测试方法组织在一起。在内部类中可以使用@BeforeEach 和@AfterEach注解,而且嵌套的层次没有限制。
76、单元测试-参数化测试
参数化测试是JUnit5很重要的一个新特性,它使得用不同的参数多次运行测试成为了可能,也为我们的单元测试带来许多便利。
利用@ValueSource等注解,指定入参,我们将可以使用不同的参数进行多次单元测试,而不需要每新增一个参数就新增一个单元测试,省去了很多冗余代码。
利用**@ValueSource**等注解,指定入参,我们将可以使用不同的参数进行多次单元测试,而不需要每新增一个参数就新增一个单元测试,省去了很多冗余代码。
@ValueSource: 为参数化测试指定入参来源,支持八大基础类以及String类型,Class类型
@NullSource: 表示为参数化测试提供一个null的入参
@EnumSource: 表示为参数化测试提供一个枚举入参
@CsvFileSource:表示读取指定CSV文件内容作为参数化测试入参
@MethodSource:表示读取指定方法的返回值作为参数化测试入参(注意方法返回需要是一个流)
当然如果参数化测试仅仅只能做到指定普通的入参还达不到让我觉得惊艳的地步。让我真正感到他的强大之处的地方在于他可以支持外部的各类入参。如:CSV,YML,JSON 文件甚至方法的返回值也可以作为入参。只需要去实现**ArgumentsProvider**接口,任何外部文件都可以作为它的入参。
Last updated