How test UI elements / get ServiceLoader working?

LaFayette

@rainova I had a different take-away from the JBrains talk. Notably that if you test end-to-end you cannot get complete coverage of all logic paths because there the logic paths combine in a combinatoral way. If you test each module individually, the number of logic path permutations becomes additive rather than combinatoral. He suggest though that end-to-end tests are still necessary, but are necessary to verify integration, not logic.

(A) I agree there are more fun things to do. On the other hand we have a track record of brittleness and needing to do a lot of manual testing.
(B) There is nobody else.
(C) In some places, pretty great. For example, you cannot change any of the the class variable name in any class that extends GameDataComponent. Another example, the battle calculator copies the entire game data on load and this copy represents the significant majority of time that the AI uses to do move computations.
(D) Good question
(E) Good question
(F) Another good question, we have more static analysis checks in place now that help, and we do code reviews.

(H) Have you read the TripleA 3.0 thread? https://forums.triplea-game.org/topic/2794/triplea-3-0-design-proposal-discussion/23

RaiNova

@LaFayette … the problem that you still needed a headed system to display the UI components

Does a linux server run the backend test? Can you equip it with a virtual screen as described in https://eclipsesource.com/blogs/2013/12/06/run-ui-tests-in-the-background-on-linux/ ?

LaFayette

@rainova Github actions (previously we used Travis) both run a within a container. The github actions are defined by each of the YML files in: https://github.com/triplea-game/triplea/tree/master/.github/workflows

I'm pretty sure, but not certain, that one can not connect a virtual screen.

RaiNova

@lafayette
Having no experience with build environments, I have to ask: Does this look promising
https://sick.codes/xfce-inside-docker-virtual-display-screen-inside-your-headless-container/
?

LaFayette

@rainova Maybe, that link is a bit skimpy on detail. FWIW you could verify some of that yourself by running that docker container. You would need to do more to have tests run from within the container or somehow to forward to the virtual env.

Though, if you did manage to get a headless container running, there are some drawbacks:

setting up yet another docker and one more built step is just one more thing
what happens if a test fails? If the UI is headless, how to tell what was incorrect? What if the results from the virtual desktop do not agree with running without docker?

LaFayette

@RaiNova I had an ulterior motive to want a well done view-model design, specifically as a good pattern for UI classes going forward and to retrofit the existing.

Check out this PR which adds one. Of note is how the UI-controller logic is tested: https://github.com/triplea-game/triplea/pull/9665/files#diff-73b2a24d2079dcf7d0b19c8777110b46bbe56a5e97fc9e4e41c875f7b98671cd

RaiNova

@lafayette Thanks for pointing me to your PR and giving me an impression how your idea regarding "Presentation Model" can be realized in TripleA! When you pointed me to "TripleA 3.0 - Design Proposal & Discussion", I read your idea to modernize TripleA by moving from Swing to JavaFX. That was a main driver to me writing "How does TripleA 3.0 have to be to attract such a community?" and

3. Technology

How much is TripleA about the end user product and how much about playing with technology?
Which technologies do we want to play with?
Shall we go web?

I am a fan of Google trends, so I looked up some UI technologies:

I recommend a discussion about the questions I posted in "TripleA 3.0 - Design Proposal & Discussion" first, then a choice of candidate technologies and a selection based on how they support a developer community and how they support design patterns and best practices that could further our goals.

Lacking such a discussion, I will have a deeper look into React. I will have your "Presentation Model" in mind as well as UI testing. I am happy to let you know my impressions and hear your opinions about them. First I have to do some programming for work (Kotlin and JavaFX including JavaFX Robot btw). Then I'll finish my PR (I am already testing to make sure my changes don't affect other use cases of UnitChooser). Then I'll look into React. (Or not - depending on what else comes up in my programming interests or my life in general.)

RaiNova

@lafayette With all the little technical issues that held me up, I can‘t say I took a dive into react, but only a glance. These are my impressions, and I would be happy to learn your pov about it:
React is technologically so far away from TripleA, that I can‘t see a convincing migration path towards it. However, it taught me some design promising principles:

There are not one but two languages for presentation models on two levels:
++ one level oriented towards the rendering engine (e.g. DOM for HTML or react-three-fiber for three.js); for simplicity I‘ll call it the DOM
++ a domain specific level
the presentation model languages are embedded in the host programming language (typically jsx-Tags which are transpiled into JavaScript; I also found a Koltin-solution using annotations, see React Functional Components with Kotlin/JS). This embedding significantly reduces the amount of code necessary only because a programming language in itself doesn‘t support a particular concept well (do you call that scaffolds?)
both presentation models are trees
the render method of the root of the domain specific model updates the DOM
the render method of each node of the domain specific model calls the render methods of its children and inserts any number of elements into the DOM
the engine does not directly render the DOM, but compares it with the DOM of the previous render and renders only the differences

This two level presentation model should lend itself nicely to automated testing.

Do you think, these concepts could be introduced into the next generation of TripleA UI? Ontop of which UI technology? Can you imagine something more topical and more attractive to potential new programmers than JavaFx?

LaFayette

@rainova said in How test UI elements / get ServiceLoader working?:

Do you think, these concepts could be introduced into the next generation of TripleA UI? Ontop of which UI technology? Can you imagine something more topical and more attractive to potential new programmers than JavaFx?

All of those require huge efforts. 3.0 is in some ways a necessary stepping stone before we can do anything else. Our effort to migrate to JavaFX failed because the UI code is too coupled and too tangled to logic and is inseparable.

There is a lot of UI code. Re-writing it is a larger effort than the initial write by an order of magnitude.

As far as adopting concepts from React, IMO we should be looking to 'reactive UI' principles to help. FWIW the new UI event queue is a step squarely in that direction.

RaiNova

@lafayette, @ssoloff, @trevan, all other developers: What are your thoughts about attracting developers? What made developers join in the past? What made them leave? Would you see making Triple A attractive for developers as an objective? Would you consider this achievable? (In that case I might start a discussion thread.)