Testing keyboard events in controls
richard.bair at oracle.com
Thu Jan 5 13:48:00 PST 2012
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
>> 5) For all other keyboard input, you can use the 'doKeyPress(KeyCode
>> keyCode, KeyModifier... modifiers)' method.
>> Any feedback would be appreciated.
More information about the openjfx-dev