[Development] QTestlib: how not to test mouseMoveEvent handling

[Jason McDonald]

On Thu, Jul 11, 2019 at 10:29 PM Volker Hilsheimer <volker.hilsheimer at qt.io>
wrote:

> 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.
>

+1.

Cheers,
--
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190722/b021d94e/attachment.html>