tags:

views:

517

answers:

2

I have a test that exercises a custom Swing component using java.awt.Robot. I'd like to run the test in our build server, but the build servers run on locked windows machines, and Robot.keyPress(char) doesn't work with the screen locked. The keystrokes I'm sending are sometimes things like down arrow and backspace, so sending them directly to the document isn't helpful.

Currently I'm just using junit's Assume to skip the tests if keyboard entry doesn't work on the first try, but I'd like to leave these test enabled. I would assume someone out there is running these kinds of tests against a Swing gui. Any ideas?

A: 

A stab in the dark: perhaps a VM (like VirtualBox) could be running in the background, but would for all intents and purposes be "awake and unlocked" as far as the robot knows. The virtual box would run your unit tests.

Jonathan Feinberg
That's a very cool idea for automating integration tests. Unfortunately, I have no control over our build environment, and even if I did, it would be overkill for fixing this single test.
Bryan Young
A: 

have you tried using the headless mode of java ? I guess java.awt.Robot won't work in this case, since it specifically depends upon awt being loaded. in such a case, one should better rely upon gui testing frameworks, like the cool (and running in headless mode) fest-swing.

Riduidel
Robot throws an exception if started in headless mode. I've used fest, but it relies on Robot as well. I've never tried getting fest to play nice with a continuous integration server, but I would think I would run into the same issues.
Bryan Young
Oh, damn, you're right ... I remember that when doing so we used, like recommended, http://www.realvnc.com/products/free/4.1/man/Xvnc.html to provide a usable AWT gui without relying upon a physical screen.
Riduidel