クロス本は、筆者のGtk/Qt/electronの経験について扱った技術エッセイのようなものです。
校正前の文章・記憶により記述し未確認の内容・雑なmarkdown風紀法・張ってないURLリンク、などがあります。
# テスト
本章では各FWにおけるテストの方法について扱う。GUIアプリケーションの主要なテストには、一般的なユニットテストと、GUIアプリケーション固有のGUIテストのテストの２つがある。
GUIテストにおいては、コールバックイベントをエミュレーションするダミーメッセージの生成と送信、画面更新および描画内容を取得して正解とdiffし結果を確認する方法、という２つの問題がある。
## Gtk
Gtkには専用のGUIテスト・ユニットテストのテストフレームワークの類はない。(無いと思う。使っているときには見あたらなかった。無いよね？)
私がGtkアプリケーションを書く際はC言語で書く。そのため、ユニットテストには[googletest]( https://github.com/google/googletest )を採用している。
C言語以外では書いたことがないのでわからないが、Gtkの各言語バインディングでも、言語ごとのデファクトなユニットテストが問題なく使えると思われる。
これは後述の、QtがC++言語を使用していながらgoogletestと衝突することのほうが、どうかしている。
コールバックイベントエミュレーションは、前述の通りフレームワークが無いので自動化していない。
コールバックテスト化のため、一応の工夫が２つある。
- コールバックエミュレーションのユニットテスト化
- 手動テスト（自動化は諦める）
である。
コールバックエミュレーションのユニットテスト化について。
Gtkコールバックループから来たマウスイベントを機能ブロックに送る前に、必要な情報のみをイベント受け渡し用に用意したstructにコピーしてから渡している。
別にGtkネイティブのstructに必要な変数を代入して使っても良いのだが、実際のイベントの取り回し等も考えて、そのような設計にしている。
実際のコード例を挙げると、vecterionの[et_tool_into機能ブロックのテスト]( https://github.com/MichinariNukazawa/vecterion_vge/blob/master/test/utest/test_et_tool_info.cpp )がある。
読んでらえれば、イベントコールバックをなんとかユニットテスト化しようとしている筆者の苦労の様子がわかる。
et_toolはツール、例えば「マウス操作によるアンカーポイント編集」などの集合である。
アプリケーションウィンドウ上でのマウス操作(EtMouseAction)と現在アクティブなツール種別( et_tool_info_util_func_*_mouse_action()関数 )を受け取り、ドキュメント上のアンカーポイントの編集操作や、ポインタの触れた位置へのフォーカス変更などを行う。
手動テスト（自動化は諦める）について。
個人によるOSSでは手動テスト・リリーステストの類のドキュメントをあまり見かけない印象があるのだが、筆者がOSSをあまり多く読んでいないだけかもしれない。
vecterionには手動による[リリーステスト]( https://github.com/MichinariNukazawa/vecterion_vge/blob/master/test/release_test.md )を用意している。
安定版をリリースする前には、リリーステストを実施することにしている。
目的はちょっとしたうっかりバグによる基本機能欠損状態でのリリースの防止。
リリーステストにより実際に、ポカミスのようなバグを何度か発見している。
リリーステスト自体の前文に書いてあるとおり、省力で済むよう心がけているのだが、それでもこんなに項目が多くなってしまうのだった。
正直、手動テスト自体が苦手なのもあり、あまりやりたくはない。
Gtkのテストについて、未調査の事項として、Gtk製の画像編集アプリケーションであるGimpをビルドした際、テストの段階でメインウィンドウと複数のダイアログが一瞬だけ立ち上がって消える。
何らかの実行テストであると思われるのだが、どのような方法で何をテストしているのかは不明。
## Qt
Qtのテストは、なんというか、ほとんどすべてがGtkと逆である。(続く)
0 件のコメント:
コメントを投稿