8235480: Regression: [RTL] Arrow keys navigation doesn't respect TableView orientation #114
After digging a bit, a couple of notes (not entirely certain if this here is the correct place for them?)
Changing existing tests
Don't know what the culture in the fx context is, but: personally I prefer to not touch existing methods. Obvious reason is that I might break a test or test the wrong thing or tweak it in any way that makes it rather useless.
An example of testing the wrong thingy on changing a test method might be test_rt18488_selectToLeft (guard against JDK-8120174). The report describes the misbehaviour as
the block added for the rtl variant does test something else for
repeating earlier comments (just to have it here for reading convenience): the goal of the parameterization is to make the test code (mostly) unaware of the parameters. In particular, if I feel the need for conditional test blocks - either in setup or in assert blocks - on the parameters, I often find out that something went wrong with the factoring. Not written in stone, though, could be me only :)
My preference would be to not touch TableViewKeyInputTest at all, but to add a new test class exclusively for testing orientation-dependent horizontal navigation by keyboard. It should focus on what's actually changed, that is the basic left/right/extend/shrink etc navigation and dynamic change of those. The class can be parameterized, the parameter being a triplet of orientation and forward/backward keys.
The emphasis on basic is intentional: I think that there is no need to cover all existing tests against bug reports nor more evolved navigation. Given all basic mappings are working as expected, everything built on top should work as well - might be wrong or there might be exceptions :)
For a bit of clarity - hopefully- of what I mean, I put togeter a raw poc example TableViewHorizontalArrowsTest)
Thanks @kleopatra for thinking through clearly about testing and providing a simpler test approach with PoC.
I have done modifications to the PoC code provided and added this test in latest commit.
Well, I disagree with your notion of "simpler" - replacing conditional blocks in tests by parameterized tests is the whole point of these. But at the end of the day, it's probably a matter of personal preferences :)
the difference between my and your code in changeNodeOrientation is that mine only changes the table's orientation and yours additionally changes the parameter nodeOrientation - resulting in your navigational methods using keys based on the orientation while mine uses those for the old orientation. Changing the parameter smells, IMO.
agreed on the overall approach, will add a couple of inline comments
@aghaisas can't see your last response here (looks like I'm fighting the system here - and loosing again ;) So copying from the mailing list:
yeah, I agree - with a minor matter: the dynamic change testing is for a single key combination only. Personally, I prefer test completeness to really grab all changes (here all key combinations): future maintainers sometimes have ideas (f.i. inlining the isRTL, and accidentally not doing it on the simple keys) which they should be protected from doing - up to you, though.
Assuming that Behaviours will move into public scope, shouldn't public/protected api documented when added (as isRtL())? Not sure about fx team internal conventions.
Anyway, all side-thought, so feel free to commit
@aghaisas This change now passes all automated pre-integration checks. When the change also fulfills all project specific requirements, type
Since the source branch of this PR was last updated there have been 28 commits pushed to the
➡️ To integrate this PR with the above commit message, type
@aghaisas The following commits have been pushed to master since your change was applied:
Your commit was automatically rebased without conflicts.
Pushed as commit 2aa8218.