Intellij Idea 当通过IDE手动运行测试失败时,如何确定maven构建成功的原因?

g0czyy6m  于 2023-04-29  发布在  Maven
关注(0)|答案(1)|浏览(193)

我有以下设置:

Apache Maven 3.8.1
Maven home: /Users/deyb/.sdkman/candidates/maven/current
Java version: 1.8.0_342, vendor: Azul Systems, Inc., runtime: /Users/myuser/.sdkman/candidates/java/8.0.342-zulu/zulu-8.jdk/Contents/Home/jre
Default locale: en_PH, platform encoding: US-ASCII
OS name: "mac os x", version: "12.3", arch: "aarch64", family: "mac"

jdk和maven安装通过sdkman在mac m1上运行。
在构建项目时,我得到了一个成功的maven构建,显示所有测试都通过了,没有失败。通过ide在一个预期失败的类上触发单元测试,虽然显示了失败的测试结果,但我无法弄清楚为什么它的行为不同。我期待它失败;但是maven build仍然会导致成功的构建
要给予更多上下文:我有一个测试类:com.sample.MySampleTest
单元测试片段

import junit.runner.Version;
...
Set<ConstraintViolation<MySample>> violations = validator.validate(dto);
        log.info("violations count >>> {}", violations.size());
        log.info("JUnit version is: " + Version.id());
        assertThat(violations, hasSize(1));

来自Maven Build的日志:

08:04:22.880 [main] INFO  c.s.MySampleTest - violations count >>> 1
08:04:22.880 [main] INFO  c.s.MySampleTest - JUnit version is: 4.12
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.014 sec

IDE导致测试失败的日志:

08:05:03.431 [main] INFO  c.s.MySampleTest - violations count >>> 0
08:05:03.431 [main] INFO  c.s.MySampleTest - JUnit version is: 4.12

java.lang.AssertionError: 
Expected: a collection with size <1>
     but: collection size was <0>

    at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
    at org.junit.Assert.assertThat(Assert.java:956)
    at org.junit.Assert.assertThat(Assert.java:923)

我尝试了以下方法,得到了这些行为:

  • 通过sdk-man结果将intellij(捆绑)和maven的maven版本与未失败的maven构建相匹配(预期失败,但日志显示所有测试运行均为0失败)
  • 删除了所有mvn安装,将其替换为IDE中捆绑的版本(将intellij插件的路径添加到zshrc),从而成功构建了maven export PATH="$PATH:/Applications/IntelliJ IDEA CE.app/Contents/plugins/maven/lib/maven3/bin";我也执行了chmod以获得正确的权限,但结果相同
  • run all tests通过intelliJ在com.sample包中显示MySampleTest测试失败(这是正确的行为)
  • run all tests通过intellj在com包上执行,在MySampleTest中显示测试失败(这是正确的行为)
  • 通过intellj在模块级执行的run all tests在MySampleTest中显示失败的测试(这是正确的行为)
  • 使用brew重新安装mvn;获得成功的maven build
  • .m2存储库中删除了junit目录以供重新下载,并执行了mvn clean install也导致成功构建
  • 使用linux机器作为构建服务器运行mvn clean install结果,以失败的构建指出失败的测试
  • 添加了一个琐碎的测试Assert.assertEquals(true, false);,并通过maven结果运行它以失败构建(这是预期的,但只报告了琐碎的测试,而不是来自MySampleTest的测试)
  • junit版本也在模块pom中显式声明(用junit.runner.Version.id()测试以确保版本匹配)

考虑到这些行为,是否有其他方法可以识别是什么原因导致通过maven cli进行的包/安装成功,即使测试失败且未被跳过?

tkclm6bt

tkclm6bt1#

就程序而言,不,它几乎是试错。然而,这里还有一些可以尝试的事情,其中一些可能与您的特定测试相关,也可能不相关:
1.检查你实际上运行相同的代码- i。即,不是先前在错误的目录中或从错误的分支等 checkout 的一些代码。(听起来很愚蠢,我知道,但经常是一个问题)
1.类似地检查它可能加载的任何测试数据是否相同

  1. CLASSPATH设置是否相同?
    1.引用的任何其他环境变量或外部资源也是如此。例如,如果这不是一个标准的集合,而是来自ORM的东西,它是否在与同一个DB进行对话?
    1.检查测试是否存在排序问题。如果你在IDE中以不同的顺序运行它们,你会得到不同的行为吗?
    1.如果这是一个多模块的maven项目?如果是这样,那么如果在模块级以不同的顺序运行测试是否有效?
    1.字符集--里面有字符串敏感的东西吗?如果是,字符集设置是否一致?(在任何地方使用UTF-8都很有帮助)
    1.有没有什么是时间敏感的。例如,如果代码被IDE或maven延迟,这会是一个因素吗?

相关问题