Best way to run gui tests without widgets becoming visible?
I am writing unit and integration tests for my QWindow app and am trying to figure out how to keep widgets from displaying during the tests. This has gone mostly well so far, with some occasional exceptions.
For example, if I select a QComboBox item using kb and mouse emulation with the following code, the list view for the QComboBox becomes visible just before and just after the selection is made:
def selectComboBoxItem(self, cb, s): self.mouseClick(cb) self.qWait(100) lv = cb.findChild(QListView) for row in range(lv.model().rowCount()): index = lv.model().index(row, 0) lv.scrollTo(index) itemP = lv.visualRect(index).center() itemS = lv.model().index(row, 0).data(Qt.DisplayRole) if not itemP.isNull() and itemS == s: self.qWait(100) self.mouseClick(lv.viewport(), Qt.LeftButton, Qt.NoModifier, itemP) return True return False
Is there a way to run gui tests without ever showing a widget? Surely this would be a requirement for any automated test system.
Is there a way to run gui tests without ever showing a widget?
Surely this would be a requirement for any automated test system.
Then the automated integration tests for Qt would not work at all...
@Christian-Ehrlicher so the qt tests pop a widget for every test that uses one? It seems like that would add quite a bit of execution time. Or am I misunderstanding you?
Yes, widgets are shown as needed. They have no physical representation until visible so depending on the test you do there’s no way to run it without them being shown.
@SGaist thanks for that. How great that we have so many examples in the qt tests to learn from.
wrosecrans last edited by
On Linux, you can run your app inside xvfb, and it'll strictly render offscreen in a virtual framebuffer. (Probably won't work if you are doing interesting OpenGL stuff, but normal widgets doing software rendering works fine.) You can even automate the generation of a screenshot at a certain point in the tests.
It's fairly easy to set up on a CI server with no GPU or actual display. The software thinking it's being displayed on a normal screen. You can set up multiple xvfb instances in parallel to act is different X displays, so you can have multiple "full screen" apps running at once, because they are all independent.