Сохранение диалога с отображением PySide для тестирования

Question

Я пишу некоторые тестовые функции для формы, которую я сделал. Есть несколько QMessageBox, которые вызывают (один через метод QMessageBox.question и один через метод QMessageBox.information. Хотя мой пользовательский виджет не отображается на экране, эти два фактически отображаются на экране.

Я попробовал уволить их с помощью цикла через виджеты я получаю в QApplication.topLevelWidgets() и отклоняя правильный, однако, кажется, что мой код только продолжает выполняться после того, как я вручную закрыть MessageBox

Так что мой вопрос два раза:.

1) Как я могу заставить QMessageBox (или любой виджет действительно) отображаться на экране во время тестирования.

2) Как я могу программно принять/отклонить/отклонить этот виджет.

Answer 1

Вы можете настроить таймер, чтобы автоматически принять диалог. Если тайм-аут долго, диалог будет по-прежнему отображаться на некоторое время:

w = QtGui.QDialog(None) 
t = QtCore.QTimer(None) 
t.timeout.connect(w.accept) 
t.start(1) 
w.exec_() 

Для вашего конкретного случая, если вы не хотите, чтобы коснуться кода, семенники, вы можете иметь таймер запустить функцию, чтобы принять все текущие модные виджеты, как вы предлагали:

def accept_all(): 
    for wid in app.topLevelWidgets(): 
     if wid.__class__ == QtGui.QDialog: #or QMessageBox, etc: 
      wid.accept() 

t = QtCore.QTimer(None) 
t.timeout.connect(accept_all) 
t.start(10) 

Answer 2

Я решил использовать вместо этого макет модуля. Казалось бы лучше, потому что другое решение действительно будет рисовать на экране, что не является оптимальным для тестирования.

Если у вас есть такая же проблема, и хотели бы, чтобы дразнить вопрос QMessageBox вы можете что-то вроде этого:

@patch.object(path.QMessageBox, "question", return_value=QtGui.QMessageBox.Yes) 

бы симулировать MessageBox, в котором была нажата кнопка Да.

Answer 3

Я думаю, что это имеет смысл с Qt-тестированием (включая PySide/PyQt), чтобы издеваться над вашим графическим интерфейсом и проводить специальное тестирование GUI отдельно по мере необходимости.

Для издевательского взаимодействия с графическим интерфейсом я бы использовал библиотеку mock, как и я сам регулярно. Недостатком этого является то, что вы должны зависеть от фальшивых определений, которые могут выходить из синхронизации по отношению к вашему производственному приложению. С другой стороны, ваши тесты будут быстрее, чем использование фактического GUI.

Для тестирования самого графического интерфейса я бы написал отдельный уровень тестов с использованием инструмента тестирования графического интерфейса, такого как Froglogic Squish. Это, как правило, приведет к более активным/более медленным испытаниям, но вы будете тестировать свое приложение напрямую, а не просто имитировать слой графического интерфейса. Мой подход в этом отношении заключается в том, чтобы инвестировать в такой инструмент, если бюджет позволяет, и проводить эти тесты по мере необходимости, имея в виду, что они будут относительно медленными.