How to unit test qt graphics view widgets/items

Question

I have an application that makes extensive use of the graphicsview architecture in Qt4 and I would like to start automated testing of the ui components, but I cannot find any resources related to what I should be testing or how to test qgraphicsview/qgraphicswidget based classes?

Answer 1

I've been running into problems trying to unit test QGraphicsView. My biggest problem was that

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

results in

Mouse event "MousePress" not accepted by receiving widget

getting written to the console, and my event handlers never getting called. The solution I've found is sending the event to the viewport, not the QGraphicsView itself:

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

which sends the event to my QGraphicsView subclass as it should. This should let you test your entire graphics view from a high level to make sure your graphics items are receiving events appropriately.

Now, on to your real questions.

Graphics-intensive classes are notoriously hard to test. Gleaning some advice from the linked pages, I would suggest to (1) separate logic and presentation as much as possible, and (2) do not test at too low a level.

Separating logic from presentation is generally good practice anyway, but it can be difficult when the bulk of your logic is spent creating the presentation! In the case of QGraphicsItem objects, we do not have convenient QTest functions to simulate events for us. So design your classes to respond to semantically meaningful events using types your can actually construct during tests, not QGraphicsSceneEvent subclasses, e.g., use

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

then have your mousePressEvent method extract the relevant information from the QGraphicsSceneMouseEvent and call your own pressed method. Your tests will then use your method, and you won't have to worry about creating artificial QGraphicsSceneEvents.

The problem of what to test is considerably harder, though. For example, you won't want to hard-code positions of graphics items into your tests. What happens when the graphics engine changes from under you and your items are rendered slightly differently? Instead, you should concentrate on semantically meaningful tests. Are these two objects colliding? Does this item's color change when I select it?

The fundamental idea here is to design and test your classes at the level of your application's semantics, not the level of the QGraphicsView. You may want a small number of well-constructed tests that test your translation of QGraphicsSceneEvents to your app's events, but understand that those are going to be more fragile than most of your tests.