BRIGHT VIE Advent Calendar 2018 - Qiita の3日目の記事です。
もう結論はタイトルの通りなのですが、
そう感じた背景などを簡単に記載できればと思います。
はじめに
弊社では、医療や介護現場で利用されるデータを様々なシステムと相互に連携するプラットフォーム「ケアデータコネクト」の開発・運営しております。
クライアントとしては、iOSアプリ/Windowsアプリ/Webブラウザといったプラットフォームにサービスを展開しており、
データ連携の際にBluetoothやNFCを利用してやりとりをすることも多くなっています。
また、サーバサイドではNode.jsを利用しており、
各IoT機器から受信したデータを解析・処理を行っております。
その際に受信するデータとしては下記のような16進数の文字列データが飛び交っており、
1480051062039000
02010612FF590080BC3C0100250B3400000000000000
02010612FF0D0082BC280100FFFFFFFF000002000000
ロジックの確認やデバッグを行う際も手動で行うには無理があるため、
嬉しいことに必然的にテストコードが必須な状態となっている状況です。
扱っているデータ
Bluetooth/NFCでは、体温計や血圧計といったバイタルを主に扱っており、
様々なメーカー様が開発された機器とBluetoothやNFCでデータの連携を行っています。
その他にもナースコールや睡眠センサー、排泄関連やマットセンサー/人感センサー/環境センサーなど様々なシステムとの連携を行っており、
JSON形式のシステムもあれば上記のようなバイナリ形式の文字列を扱ったりと、インタフェースは多種多様です。
データ連携モジュールの開発
サーバサイドはNode.JS、クライアントはJavaScriptをメインで扱っているので、
基本的には同じ仕組みでテストを実行しています。
また、各IoT機器の仕様書や実際に取得したデータをもとに
機器毎のデータ連携モジュールやテストコードがそれぞれ出来上がっていくため、
サーバ/クライアントをあまり意識せずに共通ライブラリとして構築することで
独立して開発・テストが行えることも連携機器を増やしやすい形になっているのかなと感じています。
テストの導入とテスト駆動開発の取り組み
テストの導入やテスト駆動開発そのものの方法については検索すればたくさん出てくるのでここでは記載しませんが、
初めてテストを導入される方やテスト駆動開発を行うような方には、
弊社では主にデータを解析するところから着手してもらっています。
バイナリデータなので手動で確認するには確認用のデータを準備するだけでも時間と手間がかかってしまうため、
テストが無いと辛いことを実体験で感じれるところも含めてテスト駆動開発に慣れていくことが出来ると思っています。
また、データ形式のフォーマットが決まっていたり
(2バイト リトルエンディアン形式の西暦データとか何バイト目はこういうデータなど)、
パターンの数も仕様書をベースに把握することが出来るため、
テストを書くにはピッタリの開発内容なのではないかなと感じております。
イメージとしては下記のような入力データを
[0x06, 0x69, 0x01, 0x00, 0xFF, 0xE1, 0x07, 0x0C, 0x05, 0x00, 0x20, 0x28, 0x02];
バイナリデータを解析・処理することで
{
value: 36.1
unit: "Celsius",
timestamp: 1512401560000
getType: "Body"
}
というようなJSON形式の値に変換をかけ、JavaScript / Node.JS で処理をするような形でテストケースを準備など行っております。
まとめ
弊社では全てのプロダクトにテストコードが存在しているかと言われるとそうではなく、
最低限重要な部分のみテストコードを導入している程度です。
その中でもこのバイナリデータを解析する部分にはテストが不可欠だったので、
はじめての人でもテストに慣れる、ありがたみを感じれるという意味でも
「バイナリ形式のデータを扱うプログラムはテストが必須の環境を作れるとなぁ」と感じております。
まぁ「そりゃそうだ」という部分もあったり、普段から当たり前のようにテストを導入して開発を行っている場合には全然違う意見になるとも思っていますが、
こんな意見もあっていいのかなと。。。