JmeTest API

Hello fellows,

I am currently working on this issue#1649, and i want to know your opinion (not really reviewing the PR, as it’s not finished yet, but if you want to review, feel free to do so), the PR:

Questions i want to ask about the fix:

  • Do you see any benefit from the PR ?
  • Do you think, having a JmeTestControl for AbstractControls is a good feature, currently this PR has JmeTestApp and JmeTestState
  • If you want to suggest better names/approaches, please do so !
  • Last, but not least, should i continue in this PR ? I just want an initial feedback on the benefits of this test system…

BTW, this video showcase the Testables in action :

Thanks.

Sorry, im just not sure what could get from this except easier run of some test.

You might add some general concept description :wink:

1 Like

Already at the beginning of the PR, the general approach involving filtering out some of your testcases in some packages and run them synchronously, so test by test…you can read more at the description of the PR :wink:.

Just so I understand the aim here. This is for launching test cases that a human will look at to decide if JME is working correctly. Not for automated tests. I guess I’m with @oxplay2 that I don’t understand what the aim is (the PR description jumps to how to use it not why and I can’t really follow the video). Wouldn’t an opening menu of example applications that the human tester clicks to launch make sense?

2 Likes

Yep, a gui can be built over this simply, you can read the issue also for more…it was an issue initially.

The issue was suggesting to make a better test chooser to select which testcases to debug from jme3test, so i built the pattern that will do so…and the video showcase it, to build a gui test chooser that’s another issue to address and it’s mainly will be built on top of this PR.

1 Like

ok, i think i start to understand.

so it is about to provide API that will be used by new TestChooser GUI (that will be created after this PR)

We all know current “start window” have a lot problems and there were topic with question if remove it or still have it. There were several system issues and resolution issues with multiple monitor and for me sometimes it didnt draw well.

So in general this PR is API for new GUI Testchooser(that will be created along with this PR), right?
im rather interested what will be used for new GUI there.

edit:
The api looks ok, well, its for GUI only anyway, so i belive it dont need to be super user friendly since its just for clickable TestChooser anyway.

1 Like

The GUI chooser was an idea came to me several days ago while working on thia issue, though the original issue doesn’t address any kind of GUI choosers, only backend test chooser (and that what i made in this PR, a backend API for selectively choosing which testcases to run)…

The GUI chooser should be deferred to another topic, however its easy to do so, using this backend, just define some constants and a CheckModel that will wrap those constants for the api and execute (edit: also known as MVVM pattern).

1 Like

ok, got it, thanks :slight_smile:

Sure it will help people to use this API for a TestChooser.

thanks again for explain, in my opinion API looks clear enough. I would even say it have more than expected.(signatures i mean)

1 Like

I think i should update the PR description to re-address the main issue in a clear way…

1 Like

I think we have only one option (swing), since jfx needs quite a bit of exhausting setup and differences between jdks and lemur cannot be used outside of jme.

Yes, just basic functional GUI is sufficient, no need to extra frontend stuff (something like the SettingsDialog), but to be honest, from my learned lessons while doing fullstack apps, i did a lot of mistakes and one big mistake was incorporating both the frontend and the backend in a one territory (on the same files), they should be separate and a frontend work would be just an implementation (direct call) to a backend api/code, that way we have made a user friendly maintainable api, just even users can rebuild it for their own projects !

Well, yeah that’s @Darkchaos 's idea…to use annotations to filter testcases, i just applied it in a clear way, hopefully.