This document describes some general principles upon which Jemmy is based on.
This knowledge is not really necessary to use Jemmy, but it's useful
to understand how it works.
JVM
Jemmy test is able to work only if it is executed in the same JVM as
the tested application. It allows usage of all the Java API for test purposes.
Window searching
First what any test does is window searching.
The list of frames already created is received by static java.awt.Frame.getFrames()
method. Then searching recursively on windows returned by java.awt.Window.getOwnedWindows()
method until one matching criteria is found.
The available functionality is in the org.netbeans.jemmy.WindowWaiter
class.
The criteria is defined by the org.netbeans.jemmy.ComponentChooser
interface.
Component searching
As soon as the test finds the correct window, it searches for the window's
child components. The component is searched recursively inside its container
using the java.awt.Container.getComponents() method.
Searching the criteria, again, is defined by the org.netbeans.jemmy.ComponentChooser
interface.
Event Queue
Normally, any GUI updates are performed through the java.awt.EventQueue
class.
So, for test stabilization purposes, Jemmy uses the EventQueue a lot.
Implementation is in the org.netbeans.jemmy.QueueTool class.
Some examples how the event queue is used:
After the test starts an application and finds the starting window,
it might wait until the queue empties. It would mean that all the window
drawing events have been processed, and so, the window has been completely
loaded.
Any user input simulating operations goes through the queue. Just because
this operations go there during a real user input.
Any swing component's method should be invoked through the queue. This
provides a thread-safe way to operate with components.
