Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
Hooking or harnessing a Qt app for testing by intercepting events and signals: is there timer/thread without event loop?
bootchk last edited by
I am trying to adapt Texttest/Storytext (a tool for functional testing) to Qt (currently it is for GTK and other GUI TK's.)
The tool is written in Python and basically wraps the system under test (SUT) application. For a defined set of widget/events classes, in the idle loop it walks the widget tree, introspects widget signals, and adds a layer of indirection for event/signal callbacks.
The problem is, the wrapper runs before the SUT and wants to install an idle loop handler before the QApplication is created and before there is an event loop. I can't find anyway to do that (short of subclassing QAbstractEventDispatcher, which seems like overkill.)
I am considering just starting a timer, and after the SUT has started, the timer will expire and find the event loop using QAbstractEventDIspatcher.instance(), and proceeed to harness the SUT.
But again, I don't think you can start a QTimer until a QApplication instance is created. Is there another (platform independent) mechanism in Qt for starting timers or threads that DON'T depend on the event loop? If Qt doesn't have it, am I forced to use a platform-dependent mechanism of the OS?
Or is there another way to harness?
(It seems like the tool for GTK is able to install a timer using glib gobject, before there is an event loop. I suppose I could build the Qt app using glib? Again, that seems harder than it should be.)
I don't really know the specifics of what you're using, but would "QEventLoop":http://qt-project.org/doc/qt-4.8/qeventloop.html possibly help you?
bootchk last edited by
Thanks, I don't think so. I believe it would also require a QApplication instance to exist before I can create a QEventLoop. But I will test it.
I also looked for a "starting" signal from QApplication that I could connect to. But the same chicken and the egg problem: to connect to a signal, you must know the sender. At the time I want to connect, the QApplication hasn't been created.
I also just tried a Python threading.Timer() that would delay a short time and then I would call QApplication.instance() to get a reference to the event loop. But it didn't work, I suppose because the Timer is its own OS thread, different from the thread the QApplication instance is in. That would have been portable.
So now I am trying UNIX signal SIGALRM, which is not portable.
I suppose the easiest thing is to require one change to the SUT: add a line to call the testing tool at the appropriate time.