2011-01-05 17 views
6

Tengo una aplicación que hace un uso extensivo de la arquitectura graphicsview en Qt4 y me gustaría iniciar las pruebas automatizadas de los componentes de la interfaz de usuario, pero no puedo encontrar ningún recurso relacionado con Debería probar o probar clases basadas en qgraphicsview/qgraphicswidget?Cómo probar la unidad qt gráficos ver widgets/elementos

Respuesta

8

He estado teniendo problemas al intentar probar la unidad QGraphicsView. Mi mayor problema era que

QTest::mousePressEvent(view, Qt::LeftButton, 0); 

resultados en

evento de ratón "MousePress" no aceptadas por recibir widget de

conseguir por escrito a la consola, y mis controladores de eventos no recibiendo llamadas. La solución que he encontrado es enviar el evento a la vista, no el propio QGraphicsView:

QTest::mousePressEvent(view->viewport(), Qt::LeftButton, 0); 

que envía el evento a mi QGraphicsView subclase como debería. Esto debería permitirle probar toda su vista de gráficos desde un nivel alto para asegurarse de que sus elementos gráficos reciban los eventos de manera apropiada.

Ahora, a sus verdaderas preguntas.

Las clases intensivas de gráficos son notoriouslyhard a test. Recopilando algunos consejos de las páginas vinculadas, sugiero (1) separar la lógica y la presentación tanto como sea posible, y (2) no probar a un nivel demasiado bajo.

Separar la lógica de la presentación es generalmente una buena práctica de todos modos, pero puede ser difícil cuando se gasta la mayor parte de su lógica creando la presentación. En el caso de objetos QGraphicsItem, no contamos con funciones QTest convenientes para simular eventos para nosotros. Por lo tanto el diseño de sus clases para responder a eventos significativos utilizando los tipos de su realidad puede construir semánticamente durante las pruebas, no las subclases QGraphicsSceneEvent, por ejemplo, utilizar

void MyGraphicsItem::pressed(const QPointF &pos, const QPointF &last) 

luego tener su método de mousePressEvent extraer la información relevante de la QGraphicsSceneMouseEvent y llame a su propia pressed método. Sus pruebas utilizarán su método y no tendrá que preocuparse por crear QGraphicsSceneEvents artificiales.

El problema de es muy difícil probar. Por ejemplo, no querrá codificar las posiciones de los elementos gráficos en sus pruebas. ¿Qué sucede cuando el motor de gráficos cambia debajo de usted y sus elementos se renderizan de forma ligeramente diferente? En cambio, debes concentrarte en pruebas semánticamente significativas. ¿Están colisionando estos dos objetos? ¿El color de este elemento cambia cuando lo selecciono?

La idea fundamental aquí es diseñar y probar sus clases en el nivel de la semántica de su aplicación, no el nivel de QGraphicsView. Es posible que desee una pequeña cantidad de pruebas bien elaboradas que prueben la traducción de QGraphicsSceneEvents a los eventos de su aplicación, pero comprenda que esas serán más frágiles que la mayoría de las pruebas.

+0

¿Alguna idea sobre mi pregunta vinculada? ¿Usar viewport() no parece establecer QGraphicsItem como el elemento capturador de mouse que usa este método? – paulm

Cuestiones relacionadas