On Thu, Jul 11, 2019 at 10:29 PM Volker Hilsheimer <[email protected]> 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 [email protected] https://lists.qt-project.org/listinfo/development
