2011-01-05 5 views

答えて

8

QGraphicsViewの単体テストに問題があります。私の最大の問題は

マウスイベントで

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

結果が「MousePressは、」コンソールに書き込ま取得し、私のイベントハンドラが呼び出されないばかり決してウィジェット

を受信することにより、受け入れられなかったこと。私が見つけた解決策は、ビューポート、ないQGraphicsView自体にイベントを送信している:

それが必要として私 QGraphicsViewサブクラスにイベントを送信
QTest::mousePressEvent(view->viewport(), Qt::LeftButton, 0); 

。これにより、グラフィックスアイテムが適切にイベントを受け取っていることを確認するために、グラフィックスビュー全体を高レベルからテストすることができます。

今、あなたの本当の質問に。

グラフィックス集約クラスは、notoriouslyhard~testです。リンクされたページからいくつかのアドバイスを得て、私は(1)ロジックとプレゼンテーションをできるだけ分離し、(2)あまりにも低いレベルでテストしないことをお勧めします。

プレゼンテーションからロジックを分離することは、一般的には良い方法ですが、ロジックの大部分がプレゼンテーションの作成に費やされていると、難しい場合があります。 QGraphicsItemオブジェクトの場合、私たちはイベントをシミュレートする便利なQTest関数を持っていません。だからあなたは、実際のテストではなく、QGraphicsSceneEventサブクラスの間に構築することが可能なタイプ、例えば、その後、あなたのmousePressEvent方法はQGraphicsSceneMouseEventから関連情報を抽出し、pressedあなた自身を呼び出している

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

を使用を使用することに意味的に意味のあるイベントを応答するようにクラスを設計方法。テストではメソッドが使用されるため、人工的なQGraphicsSceneEventの作成について心配する必要はありません。

の問題は、どのようなをテストするのがかなり難しいですが。たとえば、グラフィックスアイテムの位置をテストにハードコードすることは望ましくありません。グラフィックスエンジンがあなたの下から変化し、アイテムが少し違ってレンダリングされるとどうなりますか?代わりに、意味的に意味のあるテストに集中する必要があります。これらの2つのオブジェクトは衝突していますか?選択するとこのアイテムの色が変わりますか?

ここでの基本的な考え方は、QGraphicsViewのレベルではなく、アプリケーションのセマンティクスのレベルでクラスを設計してテストすることです。 QGraphicsSceneEventsのアプリケーションのイベントへの変換をテストする少数のうまく構築されたテストを望むかもしれませんが、それらはほとんどのテストよりも脆弱であることを理解しています。

+0

私のリンク先の質問はありますか? viewport()を使用しても、QGraphicsItemはこのメソッドを使用してマウスグラバー項目として設定されていませんか? – paulm

関連する問題