HEWでunityを実施する方法
私は仕事でunityを使用しています。
unityではgccでコンパイルを行うため、組み込み機器の実際のコンパイラでコンパイルをした場合と結果が異なる可能性があり、単体テストとしての品質の担保ができません。
そのため極端な話、gccのみのunityテストは、プログラマの安心のためのテストにはなっても、テストのエビデンスとして使用するのは難しいです。
多くの場合、単体テストレベルで考えた場合、gccとマイコン用コンパイラは同様の動きになるはずです。一方で、コンパイラの特性やクセによっては、微妙に動作が異なる可能性があります。
その可能性を排除するために、ターゲットコンパイラにて、単体テストを実施する必要があります。
「テスト駆動開発による組み込みプログラミング」に記載されている、組み込みＴＤＤのサイクルにおける、ステージ３です。
私はルネサスのマイコンを用いて開発を行っているため、統合開発環境としてHEWを用いています。HEWは統合開発環境としては非常にプアですが、一方でコンパイラに付属するシミュレータを動かすことができる、というメリットがあります。
ここでは、unityで作成したテストケースをHEWにてシミュレータを通して、テストする方法を説明します。
手順は以下の通りです。
- rubyのrakeを用いた、unityでのテストを行う
- HEWにて開発プロジェクトを立ち上げ、シミュレータに接続する
- unityのrubyファイルにより自動的に生成されたテストランナー及びテストファイルの１つを、HEWプロジェクトに読み込む
- プロジェクトにて、電源投入後にmain関数を呼び出すように設定し、開発プロジェクトのmain関数を削除する
- HEWにてビルドし、シミュレータを実行する
上記手順で、１つのテストファイルに対して、テストを実行することができます。上記処理をrubyスクリプトやWindowsのwsh、AutoItなどを用いて自動化し、HEWにて連続的にテストを行うことで、unityのように次々と単体テストを実行することができます（上記動作のソースコードはいずれgithubに上げる予定です）。
unityの利点である、テストケースを適当に書くと、テストランナーをrubyにより自動生成してくれる、という機能を最大限に利用し、HEWでのプロジェクトにも使用する方法です。
ただし、ここでいくつかの注意点があります。
- unityは結果表示にputcharを使用しており、マイコンによってはputcharは対応していない。その場合は、unity_internal.hのUNITY_OUTPUT_CHAR部分を書き換える必要がある。
- モックオブジェクトをfffで作成している場合、C99対応のコンパイラである必要がある。
- 実マイコン上ではROM容量が足りない場合がある。その場合は、シミュレータで指定できるもっともROM容量の大きいマイコンを選択することで問題を回避することができる。
- HEWはキーボードショートカットに対応した動作が少ない。特にビルド対象のファイルの登録はショートカットがあるものの、削除はショートカットがない。これはhwpファイルを直接書き換えることで対応できるが、面倒。
- HEWはビルド待ちなどの状態をウィンドウで表示しないため、AutoItで状態を取得するのもかなり面倒。
もしかしたら、HEWからCubesuiteに移行することで、上記のHEWの問題は解決できるかもしれません。
具体的な記載が無いですが、このようにして実コンパイラでの単体テストを行うことができます。
組み込み用途の実コンパイラでの単体テストに関してはGAIOのWinAMSが有名ですが、上記方法ではルネサスが公開しているシミュレータを使用するわけなので、GAIOのシミュレータよりも信頼性が高いかと考えています。
WinAMSとunityとでは、実際には目的が違うのですが、そこを混同する人には上記説明が有効だと考えます。
WinAMSにはC0レベルのテストケースを自動生成して実行させる機能があります。その機能を真似してunityにてテストできるツールを作成しようと思ったのですが、unityはあくまでシナリオベースのテストが目的なので意味がないと考えました（おそらく、そういう目的であればWinAMSを使用するのが正解）。
また、今後はThrow The Switchが作成しているcucumber-cを確認し、ATDDに挑戦したいです。
あるいは、AstahやEAにて描いたシーケンス図を元にテストケースを作成し、unityにて実行できるようなツールを作成したいと考えています。
