Java单元测试使用assertThrows报NoSuchMethodError求助

根因定位 #

抛出的NoSuchMethodError是典型的 测试框架版本不匹配、API跨框架混用 导致的，和你写的业务逻辑、静态方法适配没有关系：

• 编译阶段IDE加载的类路径里，存在带assertThrows(Class, ThrowingRunnable)方法的JUnit4版本，代码可以正常编译
• 运行阶段类加载器实际加载到了更低版本的JUnit4的Assert类，这个旧版本里根本没有对应签名的方法，就会触发方法不存在的报错
• 你当前的Gradle配置同时存在依赖域放错、重复引入依赖的问题，进一步放大了类加载冲突的概率。

分步修复操作 #

1. 修正build.gradle的依赖配置 #

当前依赖配置存在两处问题：

• 把JUnit5的测试依赖放到了implementation生产代码域，还重复声明了两次相同的依赖
• JUnit4和JUnit5测试栈没有做版本隔离，传递依赖容易拉取到不兼容的低版本JUnit4

参考修正后的dependencies块：

dependencies {
    // 原有生产代码依赖保留
    api 'org.apache.commons:commons-math3:3.6.1'
    implementation 'com.google.guava:guava:29.0-jre'

    // 测试专用依赖域，移除重复的JUnit5依赖，使用小版本修正的JUnit4版本
    testImplementation 'org.junit.jupiter:junit-jupiter:5.4.2'
    testImplementation 'junit:junit:4.13.2'
}

提示：如果全程使用JUnit5写测试，可以完全移除JUnit4的依赖，从根源上避免类加载冲突。

2. 统一测试代码的API导入栈 #

你当前的测试代码存在跨框架导入的割裂：

• 类上的@Test注解来自JUnit5（org.junit.jupiter.api.Test）
• 静态导入的断言方法来自JUnit4（org.junit.Assert.*）

二选一统一栈即可，不需要改动测试逻辑本身：

• 方案A（匹配现有@Test注解，推荐）：把断言的静态导入替换为JUnit5的断言类，即把原来的import static org.junit.Assert.*;换成import static org.junit.jupiter.api.Assertions.*;。JUnit5原生支持assertThrows方法，lambda写法完全兼容。
• 方案B（匹配现有断言导入）：把类上的@Test注解的导入换成JUnit4的版本，即把import org.junit.jupiter.api.Test;换成import org.junit.Test;，保留原有静态断言导入，JUnit4.13.2版本原生支持传入lambda作为异常校验的执行逻辑。

3. 关于静态方法适配的说明 #

你顾虑的“静态方法会影响Runnable适配”的问题不存在：
不管是JUnit4的ThrowingRunnable还是JUnit5的Executable，都是无参、可抛出受检异常的函数式接口，你写的()-> twoSum(testArray, 20)完全符合接口签名，不管被调用的方法是静态方法还是实例方法，都不需要额外做适配转换。

补充排查手段 #

如果修正后仍然报相同错误，可以执行Gradle依赖查看命令，确认测试运行时实际加载的JUnit版本：
./gradlew dependencies --configuration testRuntimeClasspath
如果发现有其他依赖传递引入了低于4.13版本的JUnit4包，在对应依赖块里通过exclude配置排除掉传递的旧版本JUnit即可。

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