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 .
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?
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.
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.
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.
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).
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.