For an internal application, I’ve created a Gtk.Window derived tester class, added some widgets to show current test, status, number of fails and a Gtk.Grid to attach custom widgets. This class expose some API to set a widget to test, autoclose and some signals you can use to run some tests.
GTK+ custom widget testing is no an easy task, at least it is not integrated into GTK+, making you to figure out how to add public API or signals you can use to connect to test it. Of course, you don’t have to do the same, I just starting to create this tester window class.
My widgets, are in a library then no app is used. I’ve tested each one at a time to check it constructs without warnings, making Unit Test to pass. See my post about this warnings.
Now, when I need to see if my custom widget is showing the correct information, like in a Gtk.TreeView, is hard if you don’t API exposing it; I really don’t want to expose public API to test it, because is not the intention to allow any other to interact with each internal widgets. I’m open to see if this is the correct way to do so, but for now I really would not like to do so.
When testing a GUI widget, you should be inside a GLib loop to catch signals, may be not the only one method. Catch them allows to see if the widget is sending them; if when it is raised is showing correct information to the user (requiring to add public API to access internal widgets), and so on.
I really would like to see GNOME Builder merge my work on templates, I would like to publish this class (written in Vala), to any one to use for its custom widgets testing.
Once, I’ve finished to try to use already existing Gtk.Widget signals and API, I’ll back to suggest one feature to be added to GTK+ to make them testable.
