ブログ@kaorun55

HoloLensやKinectなどのDepthセンサーを中心に書いています。

KINECTアプリケーションの自動テストについての雑感

最近、KINECTアプリケーションの開発依頼が少しずつくるようになりました。
仕事として開発する以上、クオリティを考えないといけませんし、自動テスト、CI(継続的インテグレーション)環境は、自分が健全な仕事をする上で欠かせないプラクティスです。
しかし、KINECTのようなアナログの入力に対するテスト方法が、自分の中でまだ実現できていません。そこで、今考えていることを出しつつ皆さんのアイデアをもらおうメソッドを発動してみます。

今ある情報

KINECTアプリケーションのテストについては、自分が把握している中ではこの一つしかありません

記事を読む限り、KINECTから得た情報のコンパイルのテストは出来ていますが、KINECTを使ったテストまでは至っていないようです。
#それがGoogle Mockになると思いますが、その記事はまだかなぁ。。。

前提条件

  • KINECTの入力を使ってテストしたい
  • なるべくKINECT以外のデバイスは使いたくない(asimoとかロボットとかw)

自動テストの条件

自動テストのための条件を考えたときに、自分の理解とTwitterからの返信で以下の4つを満たすものとします。

  • 固定された入力
  • 固定された出力
  • 完全独立
  • 自動検証
固定された入力

OpenNIであれば、入力データを記録する機能がある(詳しくは本を参照w)ので、それを使って最初の一度だけテストしたいデータを記録すれば出来そうです。
MS SDKSDK自体に記録機能は持ちませんが、KinecToolkitに保存、再生機能があるので、併用することで、固定された入力を実現できそうです。

固定された出力

入力が固定されれば、出力は自ずと固定されると思っているので、とくに問題ないかと思います。
懸念事項としては、OpenNIの場合、コールバックから起動する動作(主にユーザー、スケルトン)があるので、その辺りのテスト方法を考える必要がありそうです
#そこでGoogleMock?

完全独立

これはテストの順序に依存しないということだと思いますが、テストごとにデータを記録することで解決できると思います。

自動検証

ここまでのテストが実現できれば、あとはJenkinsなりTFSなりでCI環境を構築すれば、継続的な自動検証環境ができあがると思います。

まとめ

このようにモヤモヤしたイメージはあるのですが、まだ実現には至っていません。
将来的にNUIの世界が来るとは、今の時点ではあまり思わないのですが、選択肢の一つとしてのUIがある以上、それに対するテストのノウハウを貯めておく必要があるのかなーとは思っています。

気になること

MS SDKのテストはどうやったのかなぁ。。。