如何对 qt 图形视图小部件/项目进行单元测试
我有一个广泛使用 Qt4 中的 GraphicsView 架构的应用程序，我想开始 ui 组件的自动化测试，但我找不到与我应该测试的内容或如何测试相关的任何资源测试基于 qgraphicsview/qgraphicswidget 的类？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我在尝试对 QGraphicsView 进行单元测试时遇到了问题。我最大的问题是
导致
写入控制台，并且我的事件处理程序从未被调用。我找到的解决方案是将事件发送到视口，而不是 QGraphicsView 本身：
它将事件发送到我的
QGraphicsView子类，因为它应该。这应该可以让您从高级别测试整个图形视图，以确保您的图形项目正确接收事件。现在，回答你真正的问题。
图形密集型类臭名昭著很难测试。从链接页面收集一些建议，我建议（1）尽可能分离逻辑和表示，以及（2）不要在太低的级别进行测试。
无论如何，将逻辑与表示分离通常是一种很好的做法，但是当您的大部分逻辑都用于创建表示时，这可能会很困难！对于 QGraphicsItem 对象，我们没有方便的 QTest 函数来模拟事件。因此，设计您的类以使用您在测试期间实际构建的类型（而不是 QGraphicsSceneEvent 子类）来响应语义上有意义的事件，例如，使用
然后让您的
mousePressEvent方法从 QGraphicsSceneMouseEvent 中提取相关信息并调用您自己的 <代码>按下方法。然后，您的测试将使用您的方法，并且您不必担心创建人工 QGraphicsSceneEvents。不过，测试什么的问题要困难得多。例如，您不希望将图形项的位置硬编码到测试中。当图形引擎发生变化并且您的项目渲染略有不同时，会发生什么？相反，您应该专注于语义上有意义的测试。这两个物体正在碰撞吗？当我选择该项目时，它的颜色会改变吗？
这里的基本思想是在应用程序的语义级别（而不是 QGraphicsView 级别）设计和测试您的类。您可能需要少量构造良好的测试来测试 QGraphicsSceneEvents 到应用程序事件的转换，但要了解这些测试比大多数测试更脆弱。
I've been running into problems trying to unit test QGraphicsView. My biggest problem was that
results in
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:
which sends the event to my
QGraphicsViewsubclass 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
then have your
mousePressEventmethod extract the relevant information from the QGraphicsSceneMouseEvent and call your ownpressedmethod. 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.