Naturally, not the whole functionality can be tested this way.

Hmm. I depends upon what "whole functionality" you mean.

You can add any relevant information you need to the hash. For example, you could hook the size & move events and maintain a copy of the widget's size and position relative to it's parent. Relative positions ( and even sizes that specify them as percentages of the parent) are very useful as they are often less variable than absolute equivalents.

But that would be very much into the area of testing the gui manager, rather than your use of that manager. I would contend that applications should never test the libraries it uses (once you get past the POC/tools selection stage), as that is the responsibility of the library test suite. Others will disagree, but for sure, those type of tests should not be a part of unit tests.

The ultimate varient of this approach to gui testing is to install a dummy library (.dll/.so) that exposes teh same entrypoints as the gui library and forwards the entrypoints to the (renamed) real thing, having logged the api/parameters. For testing GUI managers and graphics libraries, the ultimate expression of this is to have a dummy/test display driver that sits at the bottom of the chain and logs very pixel/line/area drawn in terms of the points (in device coordinates) and colours. These logs can then be diff'd to detect anomolise between them and a benchmark file. It's very effective, but takes a lot of analysis (which is hard to automate), especially in non-determanistic environments like multi-processing/threading OSs.