JUnit 5采用注解而非类或接口的哲学原因是什么？

JUnit团队在设计时确实对接口/父类方案有过考量，最终选择注解是基于几个核心设计理念：

1. 摆脱继承/接口的约束 #

Java是单继承语言，如果要求测试类继承框架提供的父类，会直接限制测试类继承其他业务类或自定义父类的可能；即便用接口，测试类也需要实现接口定义的方法（哪怕是空实现），这会给测试类带来冗余代码。而注解是附加元数据，完全不影响类的继承结构，测试类可以自由继承任何需要的类，同时标记为测试类。

2. 支持细粒度的测试控制 #

测试逻辑不止有测试方法，还有前置初始化（@BeforeEach）、后置清理（@AfterAll）、参数化测试（@ParameterizedTest）等不同类型的方法。用接口/父类根本无法区分这些方法的角色——接口只能定义方法签名，没法标记方法的用途。注解则可以精准标记每个方法的作用，让框架清晰识别不同的测试生命周期阶段。

3. 无侵入性的设计 #

注解不会改变测试类的核心逻辑，只是给框架提供识别标记。如果用父类，测试类会继承父类的字段和方法，可能污染测试环境；接口则强制测试类实现无关方法，增加不必要的代码负担。注解完全是“无侵入”的，测试类本身依然是专注于测试逻辑的干净类。

4. 更强的扩展性 #

JUnit的注解支持自定义扩展，比如你可以创建@SmokeTest注解，配合扩展机制让框架只执行标记了该注解的测试方法。如果用接口/父类，扩展功能需要修改接口定义或继承链，灵活性极低。同时，注解可以通过反射轻松读取，框架能在运行时动态收集测试信息，支持嵌套测试、条件测试等复杂特性。

关于你提到的“测试类属性体现在类层级结构”，其实测试类的核心是包含测试逻辑，而非继承某个框架类。注解是一种更轻量的标记方式，既明确了类的测试属性，又不会限制类的其他设计需求。另外，Javadoc作为注释无法被框架可靠解析（容易写错、遗漏，且反射无法直接读取），而注解是编译/运行期可识别的元数据，能保证框架准确收集测试用例。

内容的提问来源于stack exchange，提问作者Andrew Wolfe