On 11/11/2010, at 9:59 PM, René Hansen wrote: >>> Then I would like to test application logic by sending keypresses and >>> mouseclicks on certain child elements of my application, buttons, inputs >>> etc. >> >> Another thing you might be interesting in looking at is the visual test >> infrastructure (note that it's experimental, there are no compatibility >> guarantees, etc), located in tests/auto/declarative/qmlvisual. It handles >> interaction by sending events to the scene as a whole (with e.g. the global >> position information for a mouse event) and letting the scene send the event >> to the appropriate element. > > I've looked at it and I think it's a novel idea and definitely worth > considering. It brings more decoupling of the application code and > testing code which I really like. However, I can't seem to find, that it > has any sort of formal verification, only record and playback of tests, > but I guess that is the price, if you want to have this level of > decoupling.
That's correct, the verification is primarily visual (I think there are one or two special properties you can set and check as well). We're still learning what it takes to make stable visual tests though (for example, we use a constant animation timer tick to ensure the same timing each run; we can't test same game because ball color is random and we expect pixel perfect playback; TextInput cusor blink is not consistent between runs; etc) >>> However, since I've instantiated my application in another qml file, the >>> internal id's of main are not accessible, so how do I send a click event >>> to a button for instance? >>> >>> That was why I wanted to have a getChildById method, so I could actually >>> find the element I wanted and send it whatever event. >>> >>> The way I've done it now is to enforce setting objectName on all >>> elements that I need to access to and then instead of having >>> getChildById, it's getChildByObjectName, which is just >>> QObject::findChild() wrapped. >>> >>> My point is that identical id and objectName makes for redundant code, >>> so if there was a way of addressing by id, as done in QML, it would >>> definitely help quell my OCD and make for a more DRY feel of the QML >>> code. >> >> >> I agree having to add objectName (or lots of property aliases) to production >> code simply for testing is not an ideal solution. I'm hesitant about a >> getChildById() for general QML programming, but it seems to make sense in an >> auto testing (and accessibility?) context, so maybe we should look for >> specific solutions there first (addressing e.g. the issues that Alan raised >> in another thread). > > Alan has a valid point about dynamicly created QML objects, > http://lists.trolltech.com/pipermail/qt-qml/2010-November/001542.html > > One solution might be to implicitly append or prepend the index to the > id in those cases, but I'm not sure how that would work though. In some of our autotests (written in C++) we use a variant of findChild that takes an index as well (e.g. findChild(parent, "theObject", 5)) -- that might work here as well. Regards, Michael _______________________________________________ Qt-qml mailing list Qt-qml@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-qml
