ncsで使うテストフレームワークはどれだ (7)
2024/09/25
前回の続き。
nRF Connect SDK がサポートする Testing with Unity and CMock を試す。
ncs での Unity Testのつらいところは、結果が見づらいところか。
ログとして ncs のビルドが出力され、続けてテストの結果が出力されるのでテストの結果だけ探すのが面倒。
それはまだよいのだが、これをテストするモジュールごとに行うので「ビルド→テスト結果→ビルド→テスト結果→…」と繰り返されるのでさらに探すのがつらい。
sedと組み合わせれば多少は見やすくできるかもしれない。
GATT のモック追加をあきらめる
v2.6.1 Setting up a unit testにgatt.hをモックにする記述があった。
が、${ZEPHYR_BASE}/include/bluetooth/gatt.hというファイルは無い。
latest だと cmock_handle(${ZEPHYR_BASE}/include/bluetooth/gatt.h zephyr/bluetooth) になっている。
もう、なにがなんやら。
ともかく、CMock で作られたファイルにヘッダを追加する方法はあった。
この設定は YAMLファイルなのだが、CMake で cmock_handle()などが呼ばれたときに作られるようになっている。
テンプレートのファイルにはそういうしくみがないので CMakeLists.txt とともに改造した。
そうやって直近でエラーになっていた構造体定義を含む hci_core.h を include したものの、そのファイルが参照している別の構造体定義などが別のファイルにあって・・・という感じで対応がどのくらい必要になるのかがわからん。
いったんあきらめよう。
まずは GATT API を使うような改造をしよう。
notifyの追加
前回作成した HLSサービスに、LEDの状態を読み取ったり notify できるようにしたり改造した。
LEDへの write とともに notify するだけなので意味ないが、テスト対象としてはよかろう。
テストの追加
全部ではないが使いそうなコードをgatt.hとして作った。
include guard もオリジナルの gatt.h と同じにしているので、先に include すればよいはず。
カバレッジでなぜか hls_init() だけ実行していないことになってしまうが、まあまだ許容範囲だろう。
おわりに
- 本家の
gatt.hをモックにするのはあきらめた - service は ATT の読み書きや notify/indicate の制御くらいで、ロジックは別のファイルに書くとかならそんなにテストは熱心でなくてよいのか？