単体テストあれこれ

最近、単体テストをちょっとやってます。JSTQB的に言うとコンポーネントテストです。恥ずかしながらあんまりやったことなかったのです。やっぱり僕の所属するテスト会社が受ける業務って、テストレベル的にはシステムテスト以降が多いんです。だから、あまりやったことありませんでした。

今回は車載系の案件で、ツールを使ってテストを作って、カバレッジを計測する、みたいな話です。

感想を書きます。

コンポーネントテストの意味ってなんだっけ…

ちょっとあんまり大きい声では言えないんですけど、標準とかで決まっているカバレッジ基準って「思った通りに動く」ではなくて「通った」ことがPassの基準になっているらしいんですよね。解釈の問題だとは思うんですけども。（業界的にはあるあるらしいです）

それって何の意味があるんだろう、と考えてしまうわけです。まぁコードが生きていることを証明するぐらいですかね。期待通りの動作かどうかは全く保証しないわけです。本来のコンポーネントテストの目的の10％の価値ぐらいでしょうか。感覚値ですが。

なので、形だけやっている、ということが多いんだと思います。

よりよくするには？

今回使っているツールはC0/C1を100％にするようにテストケースを作ってくれるものです。でも、ただ動くことを確認するようなテストなので、入力側しか自動生成してくれません。本来、期待通りの動作かをチェックするためには、出力側の期待値が必要です。

というわけで、期待値を決めるためには、手動で決めるか、もしくは何らかの手段で自動で生成するか、ですね。多分入力の自動生成が便利すぎて、手動で期待値入力をさせてしまうとツールの魅力が極端に落ちてしまうので、やっぱり自動で期待値生成するしかないと思うんです。

でも自動生成するには入力が必要…。ってことで、思いつきました。（普通ですけど）

自動実行してその結果をいいか悪いか判断してもらって、よければ次回以降の期待値にすればいいんです。普通ですけど。これでいいんじゃないかな。

今回実はテスト担当として別の人が書いたコードをテストしているので、そのふるまいがいいのか悪いのか判断できないのが事実なんですが、本来はこの仕組みで行けそうな気がします。