127.【SpringBoot 源码刨析D】（二）-阿里云开发者社区

127.【SpringBoot 源码刨析D】（二）

2023-09-24 51

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介： 127.【SpringBoot 源码刨析D】

(5).嵌套测试

JUnit 5 可以通过 Java 中的内部类和@Nested 注解实现嵌套测试，从而可以更好的把相关的测试方法组织在一起。在内部类中可以使用@BeforeEach 和@AfterEach 注解，而且嵌套的层次没有限制。

嵌套测试的情况下，外层的Test不能驱动内层的(Before/After)Each/All之类的方法之前/后允许。
内层可以使用外层，外层不可以使用内层

package com.jsxs;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Nested;
import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;
import java.util.EmptyStackException;
import java.util.Stack;
import static org.junit.jupiter.api.Assertions.*;
/**
 * @Author Jsxs
 * @Date 2023/7/25 15:15
 * @PackageName:com
 * @ClassName: TestingAStackDemo
 * @Description: TODO
 * @Version 1.0
 */
@SpringBootTest
@DisplayName("A stack")
class TestingAStackDemo {
    Stack<Object> stack;
    @Test
    @DisplayName("is instantiated with new Stack()")
    void isInstantiatedWithNew() {
        new Stack<>();
        // 1.嵌套测试的情况下，外层的Test不能驱动内层的(Before/After)Each/All之类的方法之前/后允许
        assertNull(stack);
    }
    // 内部嵌套一个类，我们需要使用注解 @Nested
    @Nested
    @DisplayName("when new")
    class WhenNew {
        @BeforeEach
        void createNewStack() {
            stack = new Stack<>();
        }
        // 会成功,因为我们没有向栈中推入数据
        @Test
        @DisplayName("is empty")
        void isEmpty() {
            assertTrue(stack.isEmpty());
        }
        // 会成功,因为我们栈中无数据又移除肯定报异常 -> pop移除
        @Test
        @DisplayName("throws EmptyStackException when popped")
        void throwsExceptionWhenPopped() {
            assertThrows(EmptyStackException.class, stack::pop);
        }
        // 会成功,因为我们栈中无数据又获得第一个元素 -> pep移除
        @Test
        @DisplayName("throws EmptyStackException when peeked")
        void throwsExceptionWhenPeeked() {
            assertThrows(EmptyStackException.class, stack::peek);
        }
        // 内部嵌套一个类，我们需要使用注解 @Nested
        @Nested
        @DisplayName("after pushing an element")
        class AfterPushing {
            String anElement = "an element";
            @BeforeEach
            void pushAnElement() {
                stack.push(anElement);
            }
            // 会成功，因为我们在执行前已经推入了一个数据。
            @Test
            @DisplayName("it is no longer empty")
            void isNotEmpty() {
                assertFalse(stack.isEmpty());
            }
            //会成功,因为我们只添加了一个数据。 所以值匹配相等
            @Test
            @DisplayName("returns the element when popped and is empty")
            void returnElementWhenPopped() {
                assertEquals(anElement, stack.pop());
                assertTrue(stack.isEmpty());
            }
            // 会成功,因为我们查看的第一个值就是这个
            @Test
            @DisplayName("returns the element when peeked but remains not empty")
            void returnElementWhenPeeked() {
                assertEquals(anElement, stack.peek());
                assertFalse(stack.isEmpty());
            }
        }
    }
}

(6).参数化测试

参数化测试是JUnit5很重要的一个新特性，它使得用不同的参数多次运行测试成为了可能，也为我们的单元测试带来许多便利。

利用@ValueSource等注解，指定入参，我们将可以使用不同的参数进行多次单元测试，而不需要每新增一个参数就新增一个单元测试，省去了很多冗余代码。

@ValueSource: 为参数化测试指定入参来源，支持八大基础类以及String类型,Class类型
@NullSource: 表示为参数化测试提供一个null的入参
@EnumSource: 表示为参数化测试提供一个枚举入参
@CsvFileSource：表示读取指定CSV文件内容作为参数化测试入参
@MethodSource：表示读取指定方法的返回值作为参数化测试入参(注意方法返回需要是一个流)

当然如果参数化测试仅仅只能做到指定普通的入参还达不到让我觉得惊艳的地步。让我真正感到他的强大之处的地方在于他可以支持外部的各类入参。如:CSV,YML,JSON 文件甚至方法的返回值也可以作为入参。只需要去实现ArgumentsProvider接口，任何外部文件都可以作为它的入参。

@ParameterizedTest
    @ValueSource(strings = {"one", "two", "three"})
    @DisplayName("参数化测试1")
    public void parameterizedTest1(String string) {
        System.out.println(string);
        Assertions.assertTrue(StringUtils.isNotBlank(string));
    }
    @ParameterizedTest
    @MethodSource("method")    //指定方法名
    @DisplayName("方法来源参数")
    public void testWithExplicitLocalMethodSource(String name) {
        System.out.println(name);
        Assertions.assertNotNull(name);
    }
    static Stream<String> method() {
        return Stream.of("apple", "banana");
    }

5.指标监控功能

(1).SpringBoot Actuator

(1.1).简介

未来每一个微服务在云上部署以后，我们都需要对其进行监控、追踪、审计、控制等。SpringBoot就抽取了Actuator场景，使得我们每个微服务快速引用即可获得生产级别的应用监控、审计等功能。

<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-actuator</artifactId>
        </dependency>

(1.2).1.x与2.x的不同

(1.3).如何使用

引入场景
访问 http://localhost:8080/actuator/**
暴露所有监控信息为HTTP

默认暴漏的方式是在jconsole位置，http是没有默认暴漏的有heath、和info

management:
  endpoints:
    enabled-by-default: true #暴露所有端点信息
    web:
      exposure:
        include: '*'  #以web方式暴露所有的Endpoint

启动运行后...

测试

(1.4).可视化

https://github.com/codecentric/spring-boot-admin

(2). Actuator Endpoint

如果您的应用程序是Web应用程序（Spring MVC，Spring WebFlux或Jersey），则可以使用以下附加端点：

(2.1).最常用的Endpoint

Health：监控状况
Metrics：运行时指标
Loggers：日志记录

(2.2).Health Endpoint

健康检查端点，我们一般用于在云平台，平台会定时的检查应用的健康状况，我们就需要Health Endpoint可以为平台返回当前应用的一系列组件健康状况的集合。

重要的几点：

health endpoint返回的结果，应该是一系列健康检查后的一个汇总报告
很多的健康检查默认已经自动配置好了，比如：数据库、redis等
可以很容易的添加自定义的健康检查机制

management:
  endpoints:
    enabled-by-default: true #暴露所有端点信息的开关
    web:
      exposure:
        include: '*'  #以web方式暴露所有端点信息
  endpoint:  # 对具体的断点具体配置
    health:  # 我们配置健康信息的详细一致展示
      show-details: always

(2.3).Metrics Endpoint

提供详细的、层级的、空间指标信息，这些信息可以被pull（主动推送）或者push（被动获取）方式得到；

通过Metrics对接多种监控系统
简化核心Metrics开发
添加自定义Metrics或者扩展已有Metrics