我有以下设置:
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进行的包/安装成功,即使测试失败且未被跳过?
1条答案
按热度按时间tkclm6bt1#
就程序而言,不,它几乎是试错。然而,这里还有一些可以尝试的事情,其中一些可能与您的特定测试相关,也可能不相关:
1.检查你实际上运行相同的代码- i。即,不是先前在错误的目录中或从错误的分支等 checkout 的一些代码。(听起来很愚蠢,我知道,但经常是一个问题)
1.类似地检查它可能加载的任何测试数据是否相同
1.引用的任何其他环境变量或外部资源也是如此。例如,如果这不是一个标准的集合,而是来自ORM的东西,它是否在与同一个DB进行对话?
1.检查测试是否存在排序问题。如果你在IDE中以不同的顺序运行它们,你会得到不同的行为吗?
1.如果这是一个多模块的maven项目?如果是这样,那么如果在模块级以不同的顺序运行测试是否有效?
1.字符集--里面有字符串敏感的东西吗?如果是,字符集设置是否一致?(在任何地方使用UTF-8都很有帮助)
1.有没有什么是时间敏感的。例如,如果代码被IDE或maven延迟,这会是一个因素吗?