小菜鸟

Spring Boot 单元测试详解：从基础配置到 Web 安全测试实战

单元测试是保障代码质量的关键环节，Spring Boot 基于 Spring 单元测试框架提供了更简洁的测试支持，涵盖普通 Bean 测试、Web 接口测试、安全权限测试等场景。从 “Spring 传统测试 vs Spring Boot 测试→基础测试配置→Web 接口测试（MockMvc）→安全测试（Spring Security）” 四个维度，系统讲解 Spring Boot 单元测试的实现方法与最佳实践。

Spring 传统测试与 Spring Boot 测试的核心差异

在 Spring Boot 出现前，传统 Spring 项目的单元测试需要手动配置上下文、指定配置文件，步骤繁琐；而 Spring Boot 通过 @SpringBootTest 注解简化了配置，实现 “零 XML 配置” 的测试环境搭建。

Spring Boot 基础单元测试：环境搭建与普通 Bean 测试

Spring Boot 基础测试主要用于验证普通 Bean（如配置类、Service 类）的逻辑正确性，核心是通过 @SpringBootTest 自动加载 Spring 上下文，注入待测试 Bean。

引入测试依赖

Spring Boot 提供 spring-boot-starter-test 依赖，包含 JUnit、Spring Test、MockMvc 等核心测试组件，无需单独引入其他依赖：

享元模式（Flyweight Pattern）：通过共享优化大量细粒度对象

享元模式是结构型设计模式的一种，核心思想是通过共享技术有效支持大量细粒度对象，减少内存占用和对象创建开销。它将对象的状态分为 “内部状态”（可共享、不变）和 “外部状态”（不可共享、可变），通过共享内部状态实现对象复用，本质是 “分离与共享”。

享元模式的核心结构

享元模式通过四个角色实现对象的共享与管理，分工明确：

享元接口（Flyweight）

• 定义享元对象的公共接口，声明接收外部状态的方法。
• 示例：Character接口（定义字符的显示方法，接收位置等外部状态）。

具体享元（ConcreteFlyweight）

• 实现享元接口，封装内部状态（可共享的不变数据），并通过接口接收外部状态（可变数据）。
• 示例：ConcreteCharacter（存储字符的字形等内部状态，接收坐标等外部状态）。

非共享享元（UnsharedConcreteFlyweight）

• 不需要共享的享元对象，通常包含无法共享的外部状态，直接实例化无需缓存。
• 示例：SpecialCharacter（特殊符号，使用频率低且状态独特，无需共享）。

享元工厂（FlyweightFactory）

• 负责创建和管理享元对象，维护享元池（缓存已创建的享元），确保相同内部状态的对象只被创建一次。
• 示例：CharacterFactory（缓存字符对象，根据字符值返回共享实例）。

核心概念：内部状态与外部状态

享元模式的关键是对对象状态的拆分：

桥接模式（Bridge Pattern）：拆分继承树，实现抽象与实现的独立演化

桥接模式是结构型设计模式的一种，核心思想是将抽象部分与实现部分分离，使两者可以独立变化。它通过 “组合” 替代 “继承”，解决了因多维度变化导致的 “类爆炸” 问题，让抽象和实现能够沿着各自的维度灵活扩展。

桥接模式的核心结构

桥接模式通过四个核心角色实现抽象与实现的分离，形成清晰的 “桥接” 关系：

实现部分（Implementor）

• 定义实现部分的接口，声明具体实现的基本操作（与抽象部分的业务逻辑无关，仅提供底层能力）。
• 示例：DrawingAPI（绘图接口，定义绘制图形的底层方法）。

具体实现（ConcreteImplementor）

• 实现 Implementor 接口，提供具体的底层实现（如不同的技术、平台、工具等）。
• 示例：OpenGLAPI、DirectXAPI（分别基于 OpenGL 和 DirectX 的绘图实现）。

抽象部分（Abstraction）

• 定义抽象部分的接口，包含对实现部分的引用（通过组合关联 Implementor），并声明高层业务逻辑。
• 示例：Shape（图形抽象类，持有DrawingAPI的引用，定义图形的绘制逻辑）。

扩展抽象（RefinedAbstraction）

• 扩展抽象部分的接口，添加更具体的业务逻辑，但不直接涉及实现细节（依赖实现部分的接口完成操作）。
• 示例：Circle、Rectangle（具体图形，继承Shape并扩展其功能）。

代码实现示例

以 “跨平台图形绘制” 为例：抽象部分为 “图形”（如圆形、矩形），实现部分为 “绘图 API”（如 OpenGL、DirectX），桥接模式使图形与绘图技术独立变化。

1. 实现部分（Implementor 与 ConcreteImplementor）

解释器模式（Interpreter Pattern）：自定义语言的解析与执行

解释器模式是行为型设计模式的一种，核心思想是为特定语言定义语法规则，并构建一个解释器来解析和执行该语言的句子。它就像一个 “迷你虚拟机”，能理解自定义的语法规则并按规则执行相应操作，本质是 “分离语法实现，解释执行句子”。

解释器模式的核心结构

解释器模式通过四个核心角色实现语法解析与执行，层次分明且分工明确：

抽象表达式（AbstractExpression）

• 定义所有解释器的公共接口，声明一个interpret(Context context)方法，用于解释句子（处理上下文并返回结果）。
• 示例：Expression（表达式接口，声明interpret()方法）。

终结符表达式（TerminalExpression）

• 实现抽象表达式接口，处理语法中的终结符（语法中不可再分的基本元素）。
• 示例：NumberExpression（解析数字）、VariableExpression（解析变量）。

非终结符表达式（NonterminalExpression）

• 实现抽象表达式接口，处理语法中的非终结符（由多个终结符或非终结符组合而成的复杂规则）。
• 示例：AddExpression（解析加法运算）、MultiplyExpression（解析乘法运算）。

上下文（Context）

• 存储解释器需要的全局信息（如变量映射、中间结果），为解释过程提供数据支持。
• 示例：MathContext（存储变量的值，如x=5、y=3）。

代码实现示例

以 “简单数学表达式解析器” 为例，展示解释器模式的实现：支持整数、变量及加法运算（如x + 3、5 + y）。

组合模式（Composite Pattern）：构建 “部分 - 整体” 的树形结构

组合模式是结构型设计模式的一种，核心思想是将对象组合成树形结构以表示 “部分 - 整体” 的层次关系，使客户端对单个对象（叶子节点）和组合对象（容器节点）的使用具有一致性。这种模式就像文件系统中的 “文件夹 - 文件” 结构，无论是单个文件还是文件夹（包含多个文件），都可以用统一的方式操作。

组合模式的核心结构

组合模式通过三个核心角色构建树形结构，实现对 “部分” 和 “整体” 的统一处理：

抽象组件（Component）

• 定义所有组件（叶子节点和组合节点）的公共接口，声明了添加、移除子组件、获取子组件及核心业务方法。
• 示例：FileSystemNode（文件系统节点接口，定义getName()、getSize()等方法）。

叶子节点（Leaf）

• 表示树形结构中的最小单元（不可再包含子组件），实现抽象组件的接口，但不支持子组件操作（如添加、移除）。
• 示例：File（文件，不可包含子节点）。

组合节点（Composite）

• 表示树形结构中的容器（可包含子组件，子组件可以是叶子节点或其他组合节点），实现抽象组件的接口，负责管理子组件（添加、移除、遍历）。
• 示例：Folder（文件夹，可包含文件或子文件夹）。

代码实现示例

以 “文件系统” 为例，展示组合模式的实现：文件夹（Composite）可包含文件（Leaf）或子文件夹，客户端可统一获取大小、打印结构等。

1. 抽象组件（Component）