二週間ほど前にはなりますが、 日本のTDD(テスト駆動開発)の先駆者である和田さん(t_wada)をお招きして、 技術相談会を行いました。
日頃、開発時に感じていた悩みを聞いていただき、 和田さんにビシバシと解決していただきました。
そこで今回は特に印象に残った、
- 不安定なテストとの付き合い方
- フレームワーク選定基準
- 品質保証のやり方
について書こうと思います。
不安定なテストとの付き合い方
私たちは、普段から不安定なテストに悩まされていました。
不安定なテストとは、
- ローカルでは通るけどCIでは落ちる
- 遅くてタイムアウトになるときがある
など、コードでなく環境によって結果が左右されるテストのことです。
この不安定なテストによって、開発に新しく関わった人に毎回同じような説明をしたり、説明をし忘れて不要な対応に時間をとられてしまったりということが起きていました。
どうすれば、不安定なテストとうまく付き合えるのか? 和田さんは テストにタグをつける という方法を教えて下さいました。
テストにタグをつけることでテストの特性(遅い、CIで落ちやすいなど)を明示することができます。 加えて、不安定タグだったらrebuildなどルールを決めておけば、説明する時間や無駄な対応などがなくなります。
また、環境や操作ごと(コミット時、マージ時など)に行うテストを分けることもでき、効率的にテストを行うことができます。
フレームワーク選定時の基準は?
最近のjavascriptフレームワークは目まぐるしい速さで進化していきます。 また、同じような機能で複数のフレームワークがあり、どのフレームワークを使うべきか悩みが尽きません。
私たちはどんなフレームワークを使うべきでしょうか?
和田さんは、フレームワーク選定基準には simple と easy の2つの軸があるとおっしゃいました。
一般的に「簡単」と言われているものはeasyに分類されます。 これは、使い方を覚えた人には使いやすいですが、何も知らない人には覚えることが多くて使いづらいということが起きるからです。
対して、simpleは「考え方が簡潔」であることを表しています。 書くべきコードは増えてしまうかもしれませんが、考え方が簡潔なので、覚えることは少なくて済みます。
覚えること | 手数 | |
---|---|---|
simple | 少 | 多 |
easy | 多 | 少 |
設定ファイルやリリースツールなど、誰かが一回設定すればみんなが使えるようになるものはeasyなものでもいいですが、ライブラリなど、みんなが一から使うものはsimpleなものの方が最終的に学習コストが少なくて済みます。
今使うべきなのはeasy, simpleどちらのフレームワークかを考えて選んでいくのが重要です。
品質保証
テストを書くようにするなど、日頃からソフトウェアの品質保証を心がけてはいましたが、 医療機器アプリとして品質を保証するにはどうしたらいいのか悩んでいました。
ソフトウェアとアプリの品質保証はどのように違うのでしょうか? 和田さんのご専門ではありませんが、ズバッと回答していただきました。
品質保証のやり方はサービスを提供しているプラットフォームによって異なります。 例えばウェブアプリとスマートフォンアプリが挙げられます。
ウェブアプリでは、バグ修正をしてサーバーにアップロードすれば、ユーザーにもその修正が自動的に反映されます。 なので、バグがあったらすぐ直すことで品質を高めることができます。
対してスマートフォンアプリでは、修正をアップロードしても、ユーザーがアップデートしてくれなければ修正が反映されません。 なので、なるべくバグをすぐ直すことよりもバグを出さないようにする方が品質向上につながります。
今までもなるべくバグを減らして、見つけたらすぐ直すようにはしていましたが、 バグとの付き合い方を俯瞰する立場から見直すいい機会になりました。
他にもTDDを始めとしたテストの知識やjsをとりまく環境など様々なお話をしていただき、とても濃密な時間を過ごすことができました。 和田さん、ありがとうございました。
CureAppではこんな濃密な時間を過ごしたいエンジニアを募集しています! http://jobs.cureapp.co.jp/engineers/