Cleaning up the Tests/Examples

[Darkchaos]

Hello guys,
one area that beginners typically stumble over is jme’s definition of a Test or an Example.

From what I know, we have 3 Types of Tests:

1. Unit Tests, that only test mathematical/logical functionality (unfortunately we don’t have many of those)
2. Examples (by this I mean the example games, mostly, because see 3)
3. Manual Function Tests that serve as example or reference implementation of 2.

Now the background of this question is that I have implemented what I called jme3-testing a few months/years ago, an attempt to use a software openGL implementation to validate the rendering correctness on Github Actions.

My goal is to expand this testing by including as much as possible from the group 3.
For instance issues with Gamma Correction or certain filters or even just trying to apply/compile a certain stack order of filters should be tested there.
We can then think about integrating this into the engine itself.
The only technical issue there is the storage of the reference images, which probably shouldn’t be on the repository directly.

Besides that, coming back to the original question, while there are almost only hybrids of 2 and 3, we should try to split them, at the cost of code duplication. This is because for a test, some lack instructions on what to look for (SSAOUI is a positive example here), others just aren’t really good examples, because a lot of stuff is built to have a fast and easy test case, which may not really deliver best practices.

What is your opinion there about?
A) Adopting jme3-testing onto those manual tests where possible
B) Making manual tests more clear (so maybe they can even be done manual, once it’s clear which are important and how they are supposed to look like)
C) Making better examples out of the current Test-examples
D) Dropping the jme3test package, which isn’t really up to java’s standards (though neither is com.jme3)
E) Unifying all real examples in jme3-examples: Currently the Tests are only really available through the SDK, which creates a Test Project, which contains classes “handpicked” from multiple artifact sources (which currently is even broken)

Thanks in Advance for your time

[pspeed]

I will just note, even as a core dev, if I want to see if some feature works as designed and how I’m supposed to use it, I will run the jme3-examples test selector and try it.

We used to call “raw examples” “test” which was a bit of a misnomer from today’s perspective. But as a dev, I really appreciate those bare bones raw examples.

I don’t know how that affects what you’re suggesting but I wanted to point it out.

[Darkchaos]

Well, my suggestion would be to enhance these tests maybe with testing instructions and maybe on the other hand create more simple examples for people that are new, where possible.

For instance a few tests just randomly create meshes by specifying a few buffers – that’s probably mostly unnecessary and especially confusing for beginners that have thir fany imported model.

I have to however correct myself in terms of E: It seems that almost every test is now in jme3-examples. I could swear it used to be different, but having that is already a big plus!

[sgold]

See issue 1290 for my position statement.

[Darkchaos]

Perfect, I’ll get to work at least for the low hanging fruit in #1290 then

[Darkchaos]

Not directly related, but if someone wants to have a look at LWJGL2 Tests failing · Issue #3 · MeFisto94/jme3-testing · GitHub that would be appreciated!

For some reason the software fails to properly load lwjgl2 classes during unit testing, it throws a ClassDefNotFoundException, which is however not properly exposed since App#start just locks until the unit test times out.

I do not have this issue on my computer, so it’s related to the java-gl software renderer docker container being used. I don’t know how to properly diagnose gradle not liking it and causing wrong classpaths or something.

Maybe it can also be achieved by bisecting the engine, because 1-2 years ago it supposedly did work.