I would like to know if I can get some information about the software testing process applicable to JME. I carry out research in the game testing area and am interested in tests applied to Game Engines. I downloaded, compiled and ran Jmonkey and reading the documentation. I’ve also already found the examples folder, which I assume is the tests folder. However, I wish understand the testing policy you use to determine quality of JME software.
For me, I am learning jmonkeyengine & native android development so throughout my learning process I used to read the java docs(most of time, w/o wiki for jme) carefully with the jme examples from github, & quick reading of jme classes, then building my own testcases from my own imagination & lessons of design patterns & when I learn something new, I keep my mind updated with very very simple testcases which involves only the minimal code to run a feature with or without logging(it depends on your needs).
There are also testing APIs from gradle team like junit testing, but I prefer simple stuff & I am more focused on core concept.
Thank you. I believe you are someone that can help me. As I said, I intend to perform an experiment that involves code coverage. For that, I need Unit tests and a way to run all those tests by command line, I think something like ant, for example. In addition, I intend to build many different test switches to check the effect of the test switch over my coverage test. Of course the data will be used to write a future paper and in this paper a will make reference to Jmonkey. So, I would like to know if it is possible to do something like that with Jmonkey test system?
Afaik, jmonkeyengine has nothing to do with this(it has no built in-testing system), you need to use gradle building tool which is ofc compatible with jme environment, check this :
For me, i do have fun taking a lot of time running my own testcases manually & do the logging stuff on my own(just regular java final classes with some logging & docs).
@Alexandre If you are writing a research paper or something, then may be a suggestion is to start first by making yourself familiar with jme ant environment & do run jme examples from github on your container, examine code by hand, observe & conclude the results with each testcase, then you build your own test cases after that you may shift to gradle junits, because junits won’t be good with you w/o jme knowledge.
Just FYI, we used to get similar questions (direct and otherwise) about 4-5 times a year… now they dwindle to maybe once a year. The results are always the same though: nothing of benefit.
I’d like to be wrong in this case but I generally classify this sort of thing as borderline spam.
Unit tests in a “code coverage” sense have almost no value without 100% code coverage and that’s practically impossible for an OpenGL library.
Thank you for your attention. In fact, all this talk is very helpful to me. I will follow your guidelines regarding the glader.
I apologize for the inconvenience. I never intended to disturb.
It’s fine… you are just in a long line of other ultimately unproductive folks.