Re: [Development] QTestlib: how not to test mouseMoveEvent handling
On Thu, Jul 11, 2019 at 10:29 PM Volker Hilsheimer 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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
On 11 Jul 2019, at 10:26, Elvis Stansvik mailto:elvst...@gmail.com>> wrote: Den tors 11 juli 2019 kl 05:54 skrev Jason McDonald mailto:macadd...@gmail.com>>: Welcome back Jason :) On Tue, Jul 9, 2019 at 1:39 AM Shawn Rutledge mailto:shawn.rutle...@qt.io>> wrote: On 8 Jul 2019, at 16:24, Volker Hilsheimer mailto:volker.hilshei...@qt.io>> wrote: Hi, 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. Elvis 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. Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
Jason McDonald (11 July 2019 05:53) wrote: > 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. Possibly: https://wiki.qt.io/Writing_good_tests Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
Den tors 11 juli 2019 kl 05:54 skrev Jason McDonald : > > On Tue, Jul 9, 2019 at 1:39 AM Shawn Rutledge wrote: > > > On 8 Jul 2019, at 16:24, Volker Hilsheimer > > > wrote: > > > > > > Hi, > > > > > > 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. Elvis > 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. > > > Yep. Cursor support can be disabled, I think that’s one reason at least. > > Another is that some platforms (i.e. Wayland) don’t allow applications to > > set cursor position. Anyway it’s heavy-handed and slow. But tests that > > need to simulate mouse hover or mouse enter/exit by sending events do need > > to ensure that the cursor is _not_ on top of the window, to avoid getting > > spurious events… and that’s usually done by QCursor::setPos(); so we can’t > > seem to get rid of it after all. > > > > https://codereview.qt-project.org/c/qt/qtbase/+/5290 seems to have put it > > into its current state… it’s old. > > I think it got that way a bit earlier than that patch. The patch > appears to just move code around without modifying any functionality. > > > But before that was https://codereview.qt-project.org/c/qt/qtbase/+/4462 > > which comments out QCursor::setPos() and sends a platform event instead… at > > least in one case. Too bad the commit message is so sparse. > > Unfortunately, our approval process wasn't followed very well for > either of those patches. Both patches were pushed through very > quickly outside the working hours of the testlib maintainer (me, in > GMT+10 timezone, where the patches were each pushed through in my > evening). If I had had an opportunity to review them I would > certainly have objected to the uninformative commit message. (Those > who were around in the Trolltech and Nokia days may remember my vocal > campaigns for meaningful commit messages, motivated by the fact that > for some years I was the poor sucker who had to read thousands of > commit messages every few months and turn them into release notes.) > > > 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. > > In the period before Qt 5, I had been hopeful that there would be an > opportunity to tidy this up and cleanly separate the true unit tests > from the others. At that time there was a team working on a separate > system-level testing framework for Qt, but that team was in Brisbane > and evaporated when the decision was made to eject Qt from Nokia and > the new system-test framework was never completed. > > Cheers, > -- > Jason > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
On Thu, Jul 11, 2019 at 5:57 PM Palaraja, Kavindra wrote: > On 11.07.19, 05:55, "Development on behalf of Jason McDonald" > wrote: > > > > 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. > > Did you mean this page: https://wiki.qt.io/Writing_Unit_Tests ? Yes, that's the one. There's a "Hints on writing reliable tests" section where this kind of advice would belong. Thanks Kavindra. (And thanks to the folks who have improved on my old text for that page.) Cheers, -- Jason ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
On 11.07.19, 05:55, "Development on behalf of Jason McDonald" wrote: 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. Did you mean this page: https://wiki.qt.io/Writing_Unit_Tests ? -- Kavindra. This e-mail and any attachment(s) are intended only for the recipient(s) named above and others who have been specifically authorized to receive them. They may contain confidential information. If you are not the intended recipient, please do not read this email or its attachment(s). Furthermore, you are hereby notified that any dissemination, distribution or copying of this e-mail and any attachment(s) is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by replying to this e-mail and then delete this e-mail and any attachment(s) or copies thereof from your system. Thank you. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
On Tue, Jul 9, 2019 at 1:39 AM Shawn Rutledge wrote: > > On 8 Jul 2019, at 16:24, Volker Hilsheimer wrote: > > > > Hi, > > > > 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 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. > Yep. Cursor support can be disabled, I think that’s one reason at least. > Another is that some platforms (i.e. Wayland) don’t allow applications to set > cursor position. Anyway it’s heavy-handed and slow. But tests that need to > simulate mouse hover or mouse enter/exit by sending events do need to ensure > that the cursor is _not_ on top of the window, to avoid getting spurious > events… and that’s usually done by QCursor::setPos(); so we can’t seem to get > rid of it after all. > > https://codereview.qt-project.org/c/qt/qtbase/+/5290 seems to have put it > into its current state… it’s old. I think it got that way a bit earlier than that patch. The patch appears to just move code around without modifying any functionality. > But before that was https://codereview.qt-project.org/c/qt/qtbase/+/4462 > which comments out QCursor::setPos() and sends a platform event instead… at > least in one case. Too bad the commit message is so sparse. Unfortunately, our approval process wasn't followed very well for either of those patches. Both patches were pushed through very quickly outside the working hours of the testlib maintainer (me, in GMT+10 timezone, where the patches were each pushed through in my evening). If I had had an opportunity to review them I would certainly have objected to the uninformative commit message. (Those who were around in the Trolltech and Nokia days may remember my vocal campaigns for meaningful commit messages, motivated by the fact that for some years I was the poor sucker who had to read thousands of commit messages every few months and turn them into release notes.) > 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. In the period before Qt 5, I had been hopeful that there would be an opportunity to tidy this up and cleanly separate the true unit tests from the others. At that time there was a team working on a separate system-level testing framework for Qt, but that team was in Brisbane and evaporated when the decision was made to eject Qt from Nokia and the new system-test framework was never completed. Cheers, -- Jason ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
> AFAIK Gatis is working on this (see > https://bugreports.qt.io/browse/QTBUG-69414 ). There is a magic define I have currently postponed that work. The goal is to move all auto tests that rely on mouse to DEFINES += QTEST_QPA_MOUSE_HANDLING. Here is an example of before vs after: https://codereview.qt-project.org/c/qt/qtbase/+/210028 Updating tests in qtbase can be done right now, so any help is welcome. For consistency, Qt Quick tests should utilize the QTEST_QPA_MOUSE_HANDLING code path as well. Cleaning up Qt Quick tests first requires resolving https://bugreports.qt.io/browse/QTBUG-69419 . Some WIP patches for Qt Quick Test lib are in https://bugreports.qt.io/browse/QTBUG-69415 , but it might be wiser to rewrite it in c++ https://bugreports.qt.io/browse/QTBUG-64837 I think it is worth spending time on this, instead of fighting with flaky or hard to read auto tests in future. From: Development on behalf of Friedemann Kleint Sent: Tuesday, July 9, 2019 8:33 AM To: development@qt-project.org Subject: Re: [Development] QTestlib: how not to test mouseMoveEvent handling Hi, AFAIK Gatis is working this (see https://bugreports.qt.io/browse/QTBUG-69414 ). There is a magic define widgets/widgets/qcombobox/qcombobox.pro:4:DEFINES += QTEST_QPA_MOUSE_HANDLING widgets/widgets/qmenu/qmenu.pro:9:DEFINES += QTEST_QPA_MOUSE_HANDLING which apparently changes behavior. Alternatively, the overloads of QTest::mouse*() that take a QWindow * can be used, which should act more sane. This might require some coordinate mapping, though. Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
Hi, AFAIK Gatis is working this (see https://bugreports.qt.io/browse/QTBUG-69414 ). There is a magic define widgets/widgets/qcombobox/qcombobox.pro:4:DEFINES += QTEST_QPA_MOUSE_HANDLING widgets/widgets/qmenu/qmenu.pro:9: DEFINES += QTEST_QPA_MOUSE_HANDLING which apparently changes behavior. Alternatively, the overloads of QTest::mouse*() that take a QWindow * can be used, which should act more sane. This might require some coordinate mapping, though. Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
On 8 Jul 2019, at 17:38, Shawn Rutledge mailto:shawn.rutle...@qt.io>> wrote: On 8 Jul 2019, at 16:24, Volker Hilsheimer mailto:volker.hilshei...@qt.io>> wrote: Hi, Executive summary: * QTest::mouseMove seems to be broken * when simulating QEvent::MouseMove events by constructing event objects, always construct them with global position The details: While trying to fix https://bugreports.qt.io/browse/QTBUG-76765 to not update the mouse cursor when the cursor-fied QGraphicsItem the mouse is on top of is disabled, I noticed the following pattern in the respective test: QTest::mouseMove(localPoint, widget); QMouseEvent event(QEvent::MouseMove, localPoint, Qt::NoButton, 0, 0); QApplication::sendEvent(widget, ); which confused me a bit. Shouldn’t QTest::mouseMove already have sent the event? Apparently not. That there is no overload that takes modifiers and keys is also strange. In the end, when running the test locally on my Mac, I never got it ot pass. What seems to happen is this: * for QWidget receivers, QTest::mouseMove just calls QCursor::setPos QCursor::setPos is not guaranteed to generate mouse events. The documentation of some overloads of that function [1] in fact explicitly advises against using that function in unit tests. Yep. Cursor support can be disabled, I think that’s one reason at least. Another is that some platforms (i.e. Wayland) don’t allow applications to set cursor position. Anyway it’s heavy-handed and slow. But tests that need to simulate mouse hover or mouse enter/exit by sending events do need to ensure that the cursor is _not_ on top of the window, to avoid getting spurious events… and that’s usually done by QCursor::setPos(); so we can’t seem to get rid of it after all. https://codereview.qt-project.org/c/qt/qtbase/+/5290 seems to have put it into its current state… it’s old. But before that was https://codereview.qt-project.org/c/qt/qtbase/+/4462 which comments out QCursor::setPos() and sends a platform event instead… at least in one case. Too bad the commit message is so sparse. 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. Thanks for digging in the history. This explains why targeting a QWindow with mouseMove synthesises an event; or at least it shows when it started doing that... If we need to have better tests that confirm that platform events are correctly received by Qt, translated into QEvents, and then routed to the correct receiver, then let’s have that. But we need to be able to stand on top of this guarantee when we test the internal logic of widgets. I need to be able to rely on basic event handling being done correctly; or in fact, I shouldn’t care when I test my unit. QTestlib is primarily a unit testing framework after all, not an integration or UI testing framework. The assumption that I can only test QGraphicsView’s hit testing logic by sending an event thought the operating system and the event system has nothing philosophical about it :) We use an object oriented language to build Qt, with hopefully well encapsulated internal states that don’t magically change randomly. If we need make sure that Qt doesn't produce any events that we don’t want, wouldn’t it be easier to disable/filter out those events (ie all input events with QEvent::spontaneous) programmatically, than to rely on QCursor::setPos? Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
Den mån 8 juli 2019 kl 16:26 skrev Volker Hilsheimer : > > Hi, > > Executive summary: > > * QTest::mouseMove seems to be broken > * when simulating QEvent::MouseMove events by constructing event objects, > always construct them with global position > > > The details: > > While trying to fix https://bugreports.qt.io/browse/QTBUG-76765 to not update > the mouse cursor when the cursor-fied QGraphicsItem the mouse is on top of is > disabled, I noticed the following pattern in the respective test: > > QTest::mouseMove(localPoint, widget); > QMouseEvent event(QEvent::MouseMove, localPoint, Qt::NoButton, 0, 0); > QApplication::sendEvent(widget, ); > > > which confused me a bit. Shouldn’t QTest::mouseMove already have sent the > event? Apparently not. That there is no overload that takes modifiers and > keys is also strange. > > In the end, when running the test locally on my Mac, I never got it ot pass. > > What seems to happen is this: > > * for QWidget receivers, QTest::mouseMove just calls QCursor::setPos > > QCursor::setPos is not guaranteed to generate mouse events. The documentation > of some overloads of that function [1] in fact explicitly advises against > using that function in unit tests. > > > * QMouseEvent uses QCursor::pos if no global position has been explicitly > provided > > A lot of tests don’t explicitly calculate and provide the global mouse > position, but some widgets use the global position (QGraphicsView, for > instance). > > Since QCursor::setPos doesn’t do much of anything on my mac when I’m logged > in (the visible mouse pointer on the screen didn’t move when running tests), > the mouse events received are not the ones the test expects to be received, > and the tests fail. > > I tried to fix this case now by always constructing QMouseEvent objects with > both local and global positions. That is easy, but a bit tedious, and that we > don’t use QTest::mouseMove suggests that this function has not been working > as one would expect for a while. We've run into this in our app's unit tests as well, and found this old bug about it: https://bugreports.qt.io/browse/QTBUG-5232 (That one was sort of inverted to what you're describing though, it would work on Mac, but not X11/Windows, but yea, it's old..) We also construct the events manually and send them. Elvis > > Perhaps someone can enlighten me why QTest::mouseMove doesn’t simulate a > QEvent like QTest::mousePress does? An overload that takes modifiers and > keys, and simply simulates the event, would be a good addition, perhaps? > > > Volker > > > [1] https://doc.qt.io/qt-5/qcursor.html#setPos-1 > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
> On 8 Jul 2019, at 16:24, Volker Hilsheimer wrote: > > Hi, > > Executive summary: > > * QTest::mouseMove seems to be broken > * when simulating QEvent::MouseMove events by constructing event objects, > always construct them with global position > > > The details: > > While trying to fix https://bugreports.qt.io/browse/QTBUG-76765 to not update > the mouse cursor when the cursor-fied QGraphicsItem the mouse is on top of is > disabled, I noticed the following pattern in the respective test: > > QTest::mouseMove(localPoint, widget); > QMouseEvent event(QEvent::MouseMove, localPoint, Qt::NoButton, 0, 0); > QApplication::sendEvent(widget, ); > > > which confused me a bit. Shouldn’t QTest::mouseMove already have sent the > event? Apparently not. That there is no overload that takes modifiers and > keys is also strange. > > In the end, when running the test locally on my Mac, I never got it ot pass. > > What seems to happen is this: > > * for QWidget receivers, QTest::mouseMove just calls QCursor::setPos > > QCursor::setPos is not guaranteed to generate mouse events. The documentation > of some overloads of that function [1] in fact explicitly advises against > using that function in unit tests. Yep. Cursor support can be disabled, I think that’s one reason at least. Another is that some platforms (i.e. Wayland) don’t allow applications to set cursor position. Anyway it’s heavy-handed and slow. But tests that need to simulate mouse hover or mouse enter/exit by sending events do need to ensure that the cursor is _not_ on top of the window, to avoid getting spurious events… and that’s usually done by QCursor::setPos(); so we can’t seem to get rid of it after all. https://codereview.qt-project.org/c/qt/qtbase/+/5290 seems to have put it into its current state… it’s old. But before that was https://codereview.qt-project.org/c/qt/qtbase/+/4462 which comments out QCursor::setPos() and sends a platform event instead… at least in one case. Too bad the commit message is so sparse. 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. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QTestlib: how not to test mouseMoveEvent handling
Hi, Executive summary: * QTest::mouseMove seems to be broken * when simulating QEvent::MouseMove events by constructing event objects, always construct them with global position The details: While trying to fix https://bugreports.qt.io/browse/QTBUG-76765 to not update the mouse cursor when the cursor-fied QGraphicsItem the mouse is on top of is disabled, I noticed the following pattern in the respective test: QTest::mouseMove(localPoint, widget); QMouseEvent event(QEvent::MouseMove, localPoint, Qt::NoButton, 0, 0); QApplication::sendEvent(widget, ); which confused me a bit. Shouldn’t QTest::mouseMove already have sent the event? Apparently not. That there is no overload that takes modifiers and keys is also strange. In the end, when running the test locally on my Mac, I never got it ot pass. What seems to happen is this: * for QWidget receivers, QTest::mouseMove just calls QCursor::setPos QCursor::setPos is not guaranteed to generate mouse events. The documentation of some overloads of that function [1] in fact explicitly advises against using that function in unit tests. * QMouseEvent uses QCursor::pos if no global position has been explicitly provided A lot of tests don’t explicitly calculate and provide the global mouse position, but some widgets use the global position (QGraphicsView, for instance). Since QCursor::setPos doesn’t do much of anything on my mac when I’m logged in (the visible mouse pointer on the screen didn’t move when running tests), the mouse events received are not the ones the test expects to be received, and the tests fail. I tried to fix this case now by always constructing QMouseEvent objects with both local and global positions. That is easy, but a bit tedious, and that we don’t use QTest::mouseMove suggests that this function has not been working as one would expect for a while. Perhaps someone can enlighten me why QTest::mouseMove doesn’t simulate a QEvent like QTest::mousePress does? An overload that takes modifiers and keys, and simply simulates the event, would be a good addition, perhaps? Volker [1] https://doc.qt.io/qt-5/qcursor.html#setPos-1 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
