Writing tests for tableview and delegate subclasses.
-
Hello!
I am writing tests for my qtableview subclass which uses a custom model and custom delegate for editable cells. I am having trouble finding examples in the qt tests for opening an editor. This was (and still is) a pain for my qlistview subclass so I am looking for example code up front.
Does anyone know where to look for good item view unit test example code?
-Patrick
-
Hello!
I am writing tests for my qtableview subclass which uses a custom model and custom delegate for editable cells. I am having trouble finding examples in the qt tests for opening an editor. This was (and still is) a pain for my qlistview subclass so I am looking for example code up front.
Does anyone know where to look for good item view unit test example code?
-Patrick
@patrickkidd
u know the QtTest module already? -
@patrickkidd
u know the QtTest module already?@raven-worx said in Writing tests for tableview and delegate subclasses.:
@patrickkidd
u know the QtTest module already?Yes, I am asking about the specifics of using it with item views. It is not always straightforward to get the intended behavior.
-
@raven-worx said in Writing tests for tableview and delegate subclasses.:
@patrickkidd
u know the QtTest module already?Yes, I am asking about the specifics of using it with item views. It is not always straightforward to get the intended behavior.
@patrickkidd
whats the special case you want to test with item views?! -
@patrickkidd
whats the special case you want to test with item views?!@raven-worx said in Writing tests for tableview and delegate subclasses.:
@patrickkidd
whats the special case you want to test with item views?!My case is pretty standard, just item delegates with custom editors. Writing basic tests for widgets is not always straightforward as they don't behave as you think they would, they need custom qWait calls, they don't respond to tab keys the right way, sometimes you have to fudge widget focus, things like that.
So my question is about finding example unit test code so I don' have to waste a ton of time debugging.
-
Did you already take a look at the qt autotests?
e.g. http://code.qt.io/cgit/qt/qtbase.git/tree/tests/auto/widgets/itemviews/qitemdelegate?h=5.3 -
Did you already take a look at the qt autotests?
e.g. http://code.qt.io/cgit/qt/qtbase.git/tree/tests/auto/widgets/itemviews/qitemdelegate?h=5.3@Christian-Ehrlicher As mentioned in the original post, yes. I looked in the tableview, list view, and itemdelegate tests and these open the editors programmatically, for example. I am trying to test the interactivity with mouse clicks for example.
-
Simulating mouse clicks will only work on xcb, not on windows. Therefore I would avoid it.
-
Simulating mouse clicks will only work on xcb, not on windows. Therefore I would avoid it.
@Christian-Ehrlicher said in Writing tests for tableview and delegate subclasses.:
Simulating mouse clicks will only work on xcb, not on windows. Therefore I would avoid it.
OK. Then are you saying that it is standard practice to write tests which programmatically interact with item views as opposed to using mouse events?
-
If you need real mouse interactions I would suggest using a framework like Squish ( https://www.froglogic.com/ )
-
If you need real mouse interactions I would suggest using a framework like Squish ( https://www.froglogic.com/ )
@Christian-Ehrlicher Yeah, that one looks like a great framework. Too bad how expensive it is though...
-
If you need real mouse interactions I would suggest using a framework like Squish ( https://www.froglogic.com/ )
I am still wondering what the common testing practices is for item views in Qt, or any other graphical elements that do no behave as straightforwardly as one would assume looking at the QTest documentation.
What does this look like in real life? Am I making a big deal out of nothing here? Do people just get by with programatic control of some widgets? What does experience say?
-
I am still wondering what the common testing practices is for item views in Qt, or any other graphical elements that do no behave as straightforwardly as one would assume looking at the QTest documentation.
What does this look like in real life? Am I making a big deal out of nothing here? Do people just get by with programatic control of some widgets? What does experience say?
@patrickkidd
there is a big difference between Unit testing and GUI testing frameworks.
The later is more complex obviously.Beside squish (which needs to be compiled against the same Qt version) there is also Ranorex (which uses the accessibility feature of Qt)
Probably there are more out there
-
So it seems that writing tests can be quite a minefield, as I expected. For example, I am trying to test editing cells in my tableview and itemdelegate subclasses. As suggested earlier in this thread, mouse double-clicks on an editable cell do not open the editor. Only calling view->openPersistentEditor() works. Fair enough.
But my delegate returns a QComboBox for the cell I am testing, and when I call cb->setCurrentIndex() the test crashes in QMetaObject::activate() called from QComboBox::setCurrentIndex(). I can't debug this because I am using python via PyQt5.
I've looked in the qt tests for qitemdelegate, qabstractitemview, and qtableview and haven't found any tricks for interacting with these widgets. These tests take a lot of brain power to read, so it is possible that I am missing something.
What gives? Is this as hard as it seems?
