TestFX headless: sending Control-A and Tab keys

[Chris Merrill]

I just enabled headless on my test suite. Tests run headless as expected, but some tests fail, which pass when run on the desktop.

Most of them are using this logic to fill in a field and tab away from it:
        clickOn(locator).push(KeyCode.CONTROL, KeyCode.A).write(text).push(KeyCode.TAB);

I have some tests that fail because they are not erasing the text in the field, others because the focus events are not being triggered by the Tab key.

It appears that neither the Control-A or Tab keys are functioning as expected when running headless.

Has anyone else encountered this? Is there another way I should be performing those two operations that would be more portable?

TIA!
Chris

[Benjamin Gudehus]

Hi Chris,

this could be the GlassRobot we need to use in a headless/monocle environment. I observed some timing problems in the past. TestFX normally uses the good'ol Robot from AWT.

maybe with a simple example with two textfields, clickOn(firstTextField), push(TAB), assertThat secondTextField is focused, we could try to identify the exact cause. if there are

problems with the timing, we could use interrupt() in FxRobot before the assertion (or WaitForAsyncUtils.waitForFxEvents() directly). 

--Benjamin

--
You received this message because you are subscribed to the Google Groups "TestFX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to testfx-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Merrill]

Thanks for the quick response!

I whipped up an example to show you. But it succeeds headless. At least, the vast majority of the time. I saw one of my two tests fail once. I investigated that and tried to reproduce in various ways, including adding some processing delays similar to what my code does, but it never happened again :(   So either this example is too simplistic to show the problem, or it is indeed a timing problem.


I've attached my SSCCE...though it doesn't appear that it will be helpful :(  It is probably worth noting that the components I'm testing do things that affect the state of the UI as keys are typed or when they loose focus. Like changing the style psuedo-class to reflect the editing state or non-UI effects such as updating the underlying data model. None of these are visually slow to the user, but are slow-ish from the code-level (on the order of milliseconds).

My original test suite has about 200 tests, mostly UI, and I have been running most of them reliably for months now. So while I'm always suspicious of my own code, I'm not planning to investigate bugs in my test code. I'll try to poke around into TestFX when I have some time.

Thanks for all your work on this...I love using TestFX :)
Chris

To unsubscribe from this group and stop receiving emails from it, send an email to testfx-discus...@googlegroups.com.