测试参数校验规则需覆盖边界与异常场景：1.用JUnit 5+AssertJ对单个及组合注解白盒测试；2.通过@WebMvcTest模拟Controller完整链路并断言400响应与错误信息；3.覆盖空字符串、类型转换失败、嵌套校验、分组校验等典型异常；4.验证全局异常处理器统一输出、多错误返回及国际化支持。
测试参数校验规则是否可靠，关键不是“写完就跑”，而是用覆盖性、可重复、贴近真实场景的方式验证它在各种边界和异常输入下的行为。下面从几个实用角度说明怎么做。
用单元测试驱动校验逻辑
推荐使用 JUnit 5 + AssertJ（或内置断言）对 DTO 或方法入参做白盒测试：
- 每个校验注解单独测：比如 @NotBlank 要覆盖 null、空字符串、纯空格字符串三种情况；@Min(1) 要测 0、-1、1、2 等值
- 组合校验一起测：例如一个字段同时有 @NotNull 和 @Size(min=3)，需验证只满足其一是否仍报错
- 用 @Validated 或 @Valid 触发校验，并捕获 ConstraintViolationException 或 MethodArgumentNotValidException（Controller 层）来断言错误信息
模拟 Controller 层完整链路
不只测 DTO，还要走通 Spring MVC 的校验流程：
- 用 @WebMvcTest 注解启动轻量 Web 上下文
- 构造 JSON 请求体（如
{"username": "", "age": -5}），调用 MockMvc 发送 POST - 断言响应状态码为 400，并检查返回的错误消息是否包含预期字段名和提示语（如 “用户名不能为空”、“年龄不能小于1”）
覆盖典型异常输入模式
别只测“明显错的”，更要关注容易被忽略的边缘情况：
立即学习“Java免费学习笔记（深入）”；
- 前端传空字符串 → 后端接收为 ""，@NotBlank 失效但 @NotNull 仍通过（因不是 null）
- 数字类型传空字符串或非数字 → 如 age="abc"，会先触发类型转换失败（400 Bad Request），而非进入 Bean Validation 阶段
- 嵌套对象校验 → 若 DTO 中含 @Valid 标记的子对象，需单独准备子对象的非法数据并验证级联报错
- 分组校验切换 → 使用 @Validated({Create.class}) 时，要分别测试 Create 分组启用/禁用下的不同字段生效情况
配合全局异常处理器验证输出一致性
确保所有校验失败最终都走统一出口：
- 在 @ControllerAdvice 的异常处理器中，检查是否能正确提取 FieldError 列表
- 测试多字段同时出错时，是否返回全部错误项（而非只第一个）
- 验证国际化 messageSource 是否生效（如 LocaleContextHolder.getLocale() 切换中文/英文时提示语是否变化）
