I notice that the LWJGL2 tests and the LWJGL3 tests share the same names. I suspect this is the reason why only half the tests can be run at a time.
So nothing suspicious at TestContextCreationLWJGL2, but it is still using the ES Render Backend, so let’s see what happens when we’ve released a fixed engine.
That being said, testRedCube4 doesn’t show any relevant output either.
Would you mind running these two tests manually and see if those timeouts disappear? Maybe I’ve planned the timeouts too tight, specifically since PBR loads an entire env probe.
That would be really dumb from gradle/junit, but definitely a thing to check out!
Edit: And I’ve double checked the blue cube, only the regular tests support moving the mouse.
I’ll also commit the fork change and cut a new release.
TestContextCreationLWJGL2 failed 3 times out of 3 when I ran it separately.
TestVerifyRenderOutputPBRLWJGL2 passed 2 times out of 3 (and failed once) when I ran it separately.
Actually running the test methods instead of classes would be more meaningful (but I don’t want to waste your time with all that), because that way we can rule out all intermittent side effects.
Anyway I expect testOpenGL30 to fail, but PBR not (and it almost succeeds).
For PBR the specifics would be interesting as well, probably the difference threshold is slightly too tight.
I don’t know how to run a single test method. Can you enlighten me?
I did that via IDE, but it appears gradle test --tests *MyTest.someMethod should do that.
1 Like
And how do you do it via IDE?
Well in IntelliJ I have a “play” button to the left of every method and a Fast Forward Button for the class to run all tests
1 Like
Oh, well. Different IDE. The JME 3.2 SDK allows me to test a single class, but not a single method.
Also: I tried many variations, but didn’t get the Gradle command-line filter argument to work.
1 Like