Testlib runs test without ever calling app.exec()

The way Qt Testlib works today is that the (wrapper) main function calls QTest::qExec(), which then eventually calls each test function via QMetaMethod::invoke().

The test function then sets up its objects, and calls e.g. QTest::qWaitForWindowActive(), which results in repeated calls to QCoreApplication::processEvents().

This is how the tests then process events, both Qt events and system events.

The problem with this approach is that the platform event dispatcher never gets a call to processEvents with the QEventLoop::EventLoopExec flag, as would normally be the case in a typical application:

QGuiApplication app;
QWindow window;
window.show();
return app.exec();

As a result, the platform event dispatcher will not be able to call the blocking versions of the system event dispatching, for example [NSApp run] on macOS.

And, since we never call [NSApp run] , [NSApp isRunning] will not be true during our testing.

This has subtle but problematic consequences for testing real world app behavior. For example, the macOS window manager (starting with macOS 13.2) will not transfer focus from a closed window to another window automatically if the app "isn't running".

A possible solution to this on a TestLib level, would be to detect the presence of a QCoreApplication::instance() in QTest::qRun(), and if found, run each test function in a queued slot, with app.exec() driving the queued invocations.

Since our non-appless-main tests are supposed to test real world application scenarios, this seems like a general improvement to our testing approach.