如何在手动运行IDE测试失败时,识别成功的Maven构建的原因?

huangapple go评论45阅读模式
英文:

How do i identify the cause of a successful maven build when manually run test via IDE fails?

问题

以下是您提供的内容的翻译:

我有以下设置:

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"

通过sdkman在Mac M1上安装了jdk和maven。

在构建项目时,我得到了一个成功的maven构建,显示所有测试都通过了,没有失败。 但是,通过IDE触发一个预期失败的类的单元测试却显示了失败的测试结果,我无法弄清楚为什么它的行为不同。我期望它会失败;但是maven构建仍然成功。

为了提供更多上下文:
例如,我有一个测试类: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构建的日志:

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)

我尝试了以下操作并获得了这些行为:

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

考虑到这些行为,还有其他方法可以确定是什么原因导致通过maven cli中的包/安装成功,即使有失败的测试而且它们没有被跳过吗?

英文:

I have the following setup:

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 and maven setup installed via sdkman running in a mac m1.

when building the project, i get a successful maven build showing all tests passed without failures.
Triggering the unit test on one of the expected failing classes via ide though shows failed tests results and i cant figure out why it is behaving differently. I am expecting it to fail; but maven build still results in a successful build

To give more context:
example i have a test class of: com.sample.MySampleTest

Unit Test Snippet

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));

Logs From 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

Logs from IDEresulting to test failed:

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)

I tried the following and got these behavior:

  • matched the maven version for both intellij(bundled) and maven via sdk-man results to non failing maven build (expecting to fail but logs show all test runs with 0 failure)
  • removed all mvn installations replacing it with the version bundled in the IDE (added the path to intellij plugins to zshrc) results to successful maven build
    export PATH="$PATH:/Applications/IntelliJ IDEA CE.app/Contents/plugins/maven/lib/maven3/bin"; also did chmod for correct permission but the results are the same
  • run all tests via intelliJ at com.sample package shows failed test in MySampleTest (this is the correct behavior)
  • run all tests via intellj executed on compackage shows failed test in MySampleTest (this is the correct behavior)
  • run all tests via intellj executed on module level shows failed test in MySampleTest (this is the correct behavior)
  • reinstalled mvn installation using brew; got successful maven build
  • removed junit directories from .m2 repository for redownload and did a mvn clean install also results to successful build
  • used a linux machine as build server to run mvn clean install results to failed build pointing out the failing test
  • added a trivial test Assert.assertEquals(true, false); and run it via maven results to failed build (which is expected but only the the trivial test is reported not the test from MySampleTest)
  • junit version also explicitly declared in the module pom (tested with junit.runner.Version.id() to insure matching versions)

Given these behavior, is there any other way to identify what is causing the package/install via maven cli to be successful even if there are failing tests and they are not skipped?

答案1

得分: 0

  1. 涉及到过程方面,不,这基本上是试错的过程。然而,以下是一些可以尝试的其他方法,其中一些可能与您的特定测试相关或不相关:

  2. 检查您是否实际上运行相同的代码,即不是之前在错误目录或错误分支中检出的代码等(听起来很蠢,但经常会出现问题)。

  3. 同样,检查可能加载的任何测试数据是否相同。

  4. CLASSPATH 设置是否相同?

  5. 其他环境变量或外部资源的设置是否相同。例如,如果这不是一个常规的集合,而是来自ORM的某些东西,它是否在底层连接到相同的数据库?

  6. 检查测试是否存在顺序问题。也就是说,如果在IDE中以不同的顺序运行它们,是否会得到不同的行为?

  7. 如果这是一个多模块的Maven项目?如果是这样,如果在模块级别以不同的顺序运行测试,是否可以正常工作?

  8. 字符集 - 是否有任何对字符串敏感的内容?如果有的话,字符集设置是否一致?(在所有地方使用UTF-8 是有帮助的)

  9. 是否有什么是时间敏感的?例如,如果代码被IDE或Maven延迟,这可能会成为一个因素吗?

英文:

In terms of a procedure, no it's pretty much trial-and-error. However, here are a few more things to try, some of which may or may not be relevant for your specific test:

  1. Check you're actually running the same code - i.e. not some code previously checked out in the wrong dir or from the wrong branch, etc. (sounds stupid I know but frequently a problem)
  2. Similarly check that any test data it may be loading is the same
  3. Are the CLASSPATH settings the same?
  4. Ditto for any other environment variables or external resources referenced. e.g. If this isn't a bog-standard collection but something from a ORM, is it talking to the same DB under the hood?
  5. Check if there's an ordering issue with the tests. i.e. If you run them in a different order in the IDE do you get different behavior?
  6. If this a multi-module maven project? If so, do the tests work if ran in a different order at the module level?
  7. Charsets - is there anything in there that's string-sensitive? If so, are the charset settings consistent? (using UTF-8 everywhere is helpful)
  8. Is there anything that's timing sensitive. e.g. If the code was delayed either by the IDE or maven could that be a factor?

huangapple
  • 本文由 发表于 2023年4月20日 04:13:44
  • 转载请务必保留本文链接:https://go.coder-hub.com/76058467.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定