On 11 Jul 2019, at 10:26, Elvis Stansvik <[email protected]<mailto:[email protected]>> wrote:
Den tors 11 juli 2019 kl 05:54 skrev Jason McDonald <[email protected]<mailto:[email protected]>>: Welcome back Jason :) On Tue, Jul 9, 2019 at 1:39 AM Shawn Rutledge <[email protected]<mailto:[email protected]>> wrote: On 8 Jul 2019, at 16:24, Volker Hilsheimer <[email protected]<mailto:[email protected]>> 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 [email protected] https://lists.qt-project.org/listinfo/development
