[Development] QTestlib: how not to test mouseMoveEvent handling
macadder1 at gmail.com
Mon Jul 22 03:47:33 CEST 2019
On Thu, Jul 11, 2019 at 10:29 PM Volker Hilsheimer <volker.hilsheimer at qt.io>
> 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 ;)
Go for it. It will be interesting to see if that change reveals any
autotests that have been silently broken for a long time.
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...
More information about the Development