It depends a lot upon what aspects of your gui you are hoping to test. For example, at any given point in the application, you might want to know:

• what controls are visible and what text they are currently displaying.

  In this case, having an entrypoint at the top level that when called, descends the window/control/widget tree querying their visibility and current contents can build up a datastructure, say a nested hash where key = control id & value = current (text) contents, and returns that datastructure to the caller for comparison against a known standard.

• Alternatively, you might need to verify the gui in terms of are the right (colours of) pixels displayed at the right positions.

  This kind of testing is really only necessary for testing gui libraries.

  Whilst the idea of taking a screen or window dump as a bitmap and then comparing it with an known standard sounds atractive (for it's simplicity if not speed), it has many problems. For example, the user may reposition or resize the window, or it may be positioned differently by the window manager when it is created.

  Does your application respect user preferences for font style/size/color choices? (If not, your visually impaired users are going to curse you.).

Depending upon your requirements, it may be sufficient for test purposes to have a global hash that each widget updates as it contents changes. Most controls have a 'Show' message/method that can be hooked for this purpose, and methods for obtaining references to their own & parent window ids (to allow proper structuring of the data), and their own 'contents'.

Testing becomes a process of taking copies of that global hash (perhaps in storable format) for comparison.