Testing keyboard events in controls

[Richard Bair]

Our SQE organization has JemmyFX, built on Jemmy which is like FEST but different. Same basic principle I think. We're hoping to get that into openjfx this month...

On Jan 4, 2012, at 4:10 AM, Roman Kennke wrote:

> Hi Jonathan,
> 
> Happy New Year to you and the whole JFX team!
> 
> Not having looked at your code yet, I am wondering if it would make
> sense to add a (java.awt.)Robot-like class to JavaFX? Maybe the AWT
> Robot can even be used directly? (after all, it generates OS level
> events, I believe it doesn't matter if it's an AWT window, JavaFX window
> or any other window).
> 
> A while ago I was thinking of building a FEST (for Swing) like testing
> framework for JavaFX (for the ThingsFX project), and I'll certainly
> start this once I have some time again. This should also be useful for
> testing inside JavaFX itself.
> 
> Cheers, Roman
> 
> Am Mittwoch, den 04.01.2012, 16:03 +1000 schrieb Jonathan Giles:
>> Hi all (and happy new year!),
>> 
>> ListView/TreeView/TableView have a heap of keyboard requirements that 
>> come in from UX. Keyboard event handling code is often fraught with 
>> complexity due to the many permutations. I'm frequently getting burnt 
>> due to subtle changes in this code causing unintended regressions.
>> 
>> I finally decided to do something about this, and have thrown together a 
>> very simple set of APIs to make it possible to write simple unit tests 
>> that test keyboard navigation. It's all very lightweight so that it can 
>> easily run as part of the JavaFX engineering continuous build (which 
>> means it fails sooner, compared to SQE tests, or even worse - when it 
>> ends up in the hands of developers!). Additionally, it's all very 
>> primitive and proof-of-concept at this stage, and I am happy to refine 
>> (and relocate) the class to provide utility in this area if it doesn't 
>> duplicate existing functionality I'm unaware of. I'm also certain I'm 
>> missing some of the details on how best to do this, so feedback is welcome.
>> 
>> Anywho, you can find the class in the rt/javafx-ui-controls project, in 
>> the test directory, in javafx.scene.control.KeyEventFirer. You can see a 
>> few unit tests that were used to flesh out the API in 
>> javafx.scene.control.ListViewKeyInputTest. I plan to add many more here, 
>> and for other controls, in the coming weeks and months.
>> 
>> These are the key pointers:
>> 1) When creating a KeyEventFirer, you must provide an EventTarget. 
>> Despite the scary name, all Nodes are EventTargets.
>> 2) I put the ListView inside a group, which is placed in a scene, which 
>> itself is placed in a stage. I show() and hide() the stage as necessary 
>> (in the setup() / tearDown() methods). Without this, events don't fire.
>> 3) I use the separate javafx.scene.control.KeyModifier class to provide 
>> zero or more keyboard modifiers (shift, alt, ctrl, meta) to the keyboard 
>> input. An enum might already exist for these modifiers, but I'm not sure...
>> 4) I have convenience methods (for my needs, anyway) for 
>> up/down/left/right keyboard inputs, in the form of 
>> 'do*ArrowPress(KeyModifier... modifiers)' methods. I'm sure more can be 
>> added...
>> 5) For all other keyboard input, you can use the 'doKeyPress(KeyCode 
>> keyCode, KeyModifier... modifiers)' method.
>> 
>> Any feedback would be appreciated.
>> 
> 
>