测试自定义注解解析的关键是单元测试注解处理器逻辑，而非注解本身；需隔离编写测试类，用样例类调用解析方法并断言结果，避免依赖框架或运行业务方法。

测试自定义注解是否被正确解析，关键不是“运行注解”，而是验证：当注解存在时，你的解析逻辑（通常是反射代码）能否准确识别、提取并执行对应行为。这本质上是单元测试你写的注解处理器，而非注解本身。

核心思路：隔离测试解析逻辑

不要把测试写在被注解标记的类里，而要单独写一个测试类，专门调用你的解析方法，并断言其结果。

• 准备一个或多个带有你自定义注解的“样例类”（可以是静态内部类，无需真实业务）
• 调用你封装好的解析方法（比如 AnnotationProcessor.process(MyTestClass.class)）
• 检查返回值、日志输出、抛出的异常，或观察副作用（如是否调用了某个 mock 方法）

以 @Log 日志注解为例

假设你定义了 @Log(description = "xxx")，并写了反射逻辑去打印日志。测试这样写：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 定义一个带 @Log 的测试方法：@Log(description="测试方法") void testMethod() {}
• 在测试中，用 testMethod.getAnnotation(Log.class) 断言注解对象不为 null
• 再断言 annotation.description() 等于 "测试方法"
• 如果解析逻辑会触发实际日志打印，可重定向 System.out 并捕获输出内容做断言

模拟 JUnit @Test 的场景

如果你模仿 JUnit 写了一个 @MyTest，并有一个 TestRunner 类负责扫描和执行标有该注解的方法：

立即学习“Java免费学习笔记（深入）”；

• 写一个测试类 TestSubject，里面包含 @MyTest 和普通方法
• 在单元测试里调用 TestRunner.run(TestSubject.class)
• 用 Mockito 或简单计数器，验证只有带 @MyTest 的方法被调用了一次
• 可额外验证未加注解的方法未被执行

避免常见误区

• 不直接运行被注解的方法来“看效果”——那测的是业务逻辑，不是注解解析
• 不依赖 Spring 或其他框架容器启动——单元测试应轻量、可独立运行
• 不测试注解声明本身（@interface）——它只是个接口，编译通过即可；重点是你读取它的代码