#13343 closed defect (fixed)
Unable to run unit tests on Windows command line
| Reported by: | GerdP | Owned by: | GerdP |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Trac | Version: | |
| Keywords: | windows command line | Cc: |
Description (last modified by )
I tried the sample shown at the bottom of
https://josm.openstreetmap.de/wiki/DevelopersGuide/Compiling#CompilingusingEclipse
This is what I get:
E:\josm\core>set TESTCP=".;test/unit:test/functional;dist/josm-custom.jar;test/lib/fest/*;test/lib/junit/*;test/lib/*;test/lib/unitils-core/*" E:\josm\core>javac -cp ".;test/unit:test/functional;dist/josm-custom.jar;test/lib/fest/*;test/lib/junit/*;test/lib/*;test/lib/unitils-core/*" test/unit/org/openstreetmap/josm/data/projection/ProjectionRefTest.java E:\josm\core>java -cp ".;test/unit:test/functional;dist/josm-custom.jar;test/lib/fest/*;test/lib/junit/*;test/lib/*;test/lib/unitils-core/*" org.junit.runner.JUnitCore org.openstreetmap.josm.data.projection.ProjectionRefTest JUnit version 4.12 .E Time: 0,002 There was 1 failure: 1) initializationError(org.junit.runner.JUnitCommandLineParseResult) java.lang.IllegalArgumentException: Could not find class [org.openstreetmap.josm.data.projection.ProjectionRefTest] at org.junit.runner.JUnitCommandLineParseResult.parseParameters(JUnitCommandLineParseResult.java:102) at org.junit.runner.JUnitCommandLineParseResult.parseArgs(JUnitCommandLineParseResult.java:50) at org.junit.runner.JUnitCommandLineParseResult.parse(JUnitCommandLineParseResult.java:44) at org.junit.runner.JUnitCore.runMain(JUnitCore.java:72) at org.junit.runner.JUnitCore.main(JUnitCore.java:36) Caused by: java.lang.ClassNotFoundException: org.openstreetmap.josm.data.projection.ProjectionRefTest at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at org.junit.internal.Classes.getClass(Classes.java:16) at org.junit.runner.JUnitCommandLineParseResult.parseParameters(JUnitCommandLineParseResult.java:100) ... 4 more FAILURES!!! Tests run: 1, Failures: 1
Attachments (2)
Change History (11)
comment:1 by , 9 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 9 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → needinfo |
comment:4 by , 9 years ago
| Component: | Unit tests → Trac |
|---|---|
| Resolution: | → fixed |
| Status: | needinfo → closed |
There was a typo (':' instead of ';'). The wiki is fixed.
by , 9 years ago
| Attachment: | 10853-build-and-test.log added |
|---|
by , 9 years ago
| Attachment: | hs_err_pid6240.log added |
|---|
comment:5 by , 9 years ago
Yes, sorry, I also noticed this and forgot to report it.
It was not the solution when I reported the problem, but with r10853 this problem
is solved. Thanks!
Still, there seems to be another problem with unit tests on Windows. I see a crash
and many "FAILED" messages, still the final message is "BUILD SUCCESSFUL". See attached files
hs_err_pid6240.log and 10853-build-and-test.log.
This crash is not new, I think I always saw it when I tried to execute the unit tests. I think I first
tried when I opened ticket #13250.
comment:6 by , 9 years ago
Yes the bug is known (see #13001) and reported to Oracle already: javabug:8159956
It's resolved in Java 9b130 but not backported to Java 8 yet
follow-up: 8 comment:7 by , 9 years ago
It seems that one of the last changes changed this so that the crash is gone now.
On the other hand, the unit tests are a bit confusing as they open new tabs in the browser or start to play
audio files. Is that intended?
follow-up: 9 comment:8 by , 9 years ago
Replying to Gerd Petermann <gpetermann_muenchen@…>:
On the other hand, the unit tests are a bit confusing as they open new tabs in the browser or start to play
audio files. Is that intended?
The goal was to maximize coverage on Jenkins, where it does not cause any problem. Maybe we could disable these tests on non-headless environments.
comment:9 by , 9 years ago
Replying to Don-vip:
Replying to Gerd Petermann <gpetermann_muenchen@…>:
On the other hand, the unit tests are a bit confusing as they open new tabs in the browser or start to play
audio files. Is that intended?
The goal was to maximize coverage on Jenkins, where it does not cause any problem. Maybe we could disable these tests on non-headless environments.
I think this would be better. Besides the spooky feeling you have to react on dialog boxes, else the test is blocked.



Have you compiled JOSM first? Using
ant clean dist