[Development] QTestlib: how not to test mouseMoveEvent handling

Volker Hilsheimer volker.hilsheimer at qt.io
Thu Jul 11 14:29:34 CEST 2019

On 11 Jul 2019, at 10:26, Elvis Stansvik <elvstone at gmail.com<mailto:elvstone at gmail.com>> wrote:

Den tors 11 juli 2019 kl 05:54 skrev Jason McDonald <macadder1 at gmail.com<mailto:macadder1 at gmail.com>>:

Welcome back Jason :)

On Tue, Jul 9, 2019 at 1:39 AM Shawn Rutledge <Shawn.Rutledge at qt.io<mailto:Shawn.Rutledge at qt.io>> wrote:
On 8 Jul 2019, at 16:24, Volker Hilsheimer <volker.hilsheimer at qt.io<mailto:volker.hilsheimer at qt.io>> wrote:


Executive summary:

* QTest::mouseMove seems to be broken
* when simulating QEvent::MouseMove events by constructing event objects, always construct them with global position

That's good advice for now.  I think it would be worth filing a bug to
see if this part of testlib can be fixed/improved in the future.  At

I think https://bugreports.qt.io/browse/QTBUG-5232 could be
re-used/re-opened for this.

It was closed with resolution "Won't Do", but with a comment

  ""Won't Do" => actually we will do this. In Qt 6 we will drop some
legacy code paths and this stuff will start working fine."

comment from Gatis.


There’s https://bugreports.qt.io/browse/QTBUG-63991 which links to a bunch of related issues in that respect. See Gatis’ reply in this thread from a few days ago.

the very least, it will make it clear that we're aware of the issue.

I also recall that there used to be a wiki page that listed some
best-practices for writing unit tests. If that list still exists
somewhere, this advice should be added there.

That there is no overload that takes modifiers and keys is also strange.

Most likely this omission is simply because nobody ever asked for such
an overload.  I'm fairly sure that that part of testlib existed before
modifiers and keys were part of the Qt API and testlib never caught up
when those were added elsewhere.

Thinking about that a bit more, having QTest::mouseMove deliver a QEvent::MouseMove that uses the button, key, and modifier states as per the previous calls to QTest::keyPress or QTest::mousePress/Release would be the correct thing to do. The widget’s internal state would not be realistic if we would deliver a mouseMove that has a button down without first sending a mousePress, after all.

The QWindow case seems to do exatly that, but the QWidget case doesn’t; will try to have a look into that, if noone else happens to beat me to it ;)

I suppose there’s the usual tradeoff between the philosophy that real platform testing should involve real platform events (in this case: if you really move the system mouse cursor, then the window system will hopefully send a mouse move event to the window, and aren’t you making the test more realistic that way?) vs. the practical tendency for that kind of testing to be less reliable, with unpredictable latency, needing to use QTRY_ much more because you don’t know how long to wait until the window system reacts, etc.

I have always been a little uncomfortable with the part of testlib
that handles mouse and keyboard events because it feels like some of
it crosses the line from unit testing into integration and system
testing, and thus really belongs in a separate system-level test
framework rather than in testlib. The system-level tests that
masqueraded as unit tests were always more likely to be flaky than
'pure' unit tests.

Agree; our Qt classes are significant and entangled enough. Dragging windowing systems and other stuff that is entirely outside of our control into this makes it much harder to test our own logic, without adding substantial coverage.

Platform interfaces like QPA could be a great opportunity to establish testable boundaries within Qt, so that we can verify “translation of events from system into Qt” separately from “handling of events inside of Qt”. We are naturally reluctant to build a lot fo tests against those interfaces, as they are private and continuously evolving. But I think it’s a better investment of our time to fix a few tests when we change private APIs, than to contstantly deal with very complex test setups and unreliable tests.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190711/3351e16a/attachment-0001.html>

More information about the Development mailing list