ソフトウェア工学について その４ テストのしやすさを考える

だんだん、ソフトウェア工学の話の中でもマイノリティなところへと突き進んでいるような気がし始めているが今日はテストしやすいプログラムを作成するということについて考えたい。

プロとしてプログラムを作るのであれば当然、きちんと動くかについて保証する必要があり、そのためにテストは必要不可欠であるからである。
さて、テストしやすくするためにはどのようにすればいいのだろうか。
ひとつ簡単な方法としては、今まで振り返ってテストしにくいものはどういったものなのかを考えてみるとわかりやすいのではないだろうか。
ここでは、テストしにくいものとして以下をあげておく

①巨大なルーチン（サブルーチンを含む）
②条件が複雑なもの
③うまく動いているのかが分かりにくいもの
④特殊なタイミングを必要とするもの
⑤メモリリーク　などなど

これらはすべてテストをやりにくくする。なぜテストがやりにくくなるのか。原因としてはだいたい以下のうなものになると思う。

①テストケースが膨大になり、コントロールできなくなる
　テストケースをいたずらに増やすようなプログラムはテストにかかる作業を増大させる。
　テストの設計、テスト実施、結果の検証等の時間がかかってしまう。
　これについてはプログラムの構造、条件判断などの設定に注意すればかなり簡単に回避することができるだろう。

②再現性を持たせることができないのでテストの終了の判断がしにくい
　問題が起きた時に再現できないのはテスト作業を増大させる。
　問題はどういった条件で起こるのか。問題はどこで起きているのかなど。
　完全に避けることはできないものの、ログの出力などを行い、問題発生個所を特定できるような構造とする癖をつけ
　ることである程度は回避することができる。

③おびただしい手順や時間を必要とする
　問題が発生するためにはたくさんの操作を行う事で発生する。
　あるいは数時間動かすと異常終了するなど。
　メモリリークなどはこれにあたる。もっとも根気を必要とする。
　lint等のツールでチェックする、あるいはコードレビューを徹底するなどして入り込まないような工夫が必要である。

次回以降、これらについてみてきたいと思う。