状態を減らしてテストケースを減らす

状態遷移とテストケースで書きましたが、「Inputs * States = Outputs = Test Cases」です。であれば、入力 や 状態 を減らせば、テストケースも減ることになります。今回は状態を減らすことを考えてみます。

プログラムにおいて「変数」は「状態遷移するオブジェクト」であり、「変数への値の代入」は「状態遷移」と言えます。オブジェクト指向プログラミングではデータはメソッドによって隠蔽されますが、メソッド呼び出しにより内部データが変更されればそのオブジェクトの状態が遷移したことになります。

では、状態を減らすにはどうすればよいでしょうか？

1. 状態（とその遷移）の絶対数を減らす
   
   
   • オブジェクト（＝変数）の数を減らす
   • オブジェクト（＝変数）に代入する値のバリエーションを減らす
   • オブジェクト（＝変数）への代入回数を減らす
2. 状態（とその遷移）の相対数を減らす
   
   
   • オブジェクト（＝変数）の寿命を短くする
   • オブジェクト（＝変数）のスコープを狭くする

1. 状態遷移の絶対数を減らす
純粋関数型言語のように言語自体で高い参照透過性が保証されている場合は別ですが、手続き型言語（やそこから発展したオブジェクト指向言語）を使用している場合は、アプリケーション全体で状態遷移を大幅に減らすことは難しいでしょう。クラスのメンバ変数を変更するメソッドが書けなくなったりします。

2. 状態遷移の相対数を減らす
たとえソフトウェアの起動から終了までに膨大な状態遷移があったとしても、Input があった時の可能なStateの数が少なければ、そのInputに対するOutputs(=Test Cases)も少なくてすむということです。こちらは絶対数を減らすのに比べて簡単です。

プログラム入門者向けの書籍にも「グローバル変数を無闇に使うな」とか「関数は長くし過ぎない」など、よく書かれています。ソースコードの可読性を高めることで、バグの混入を予防したり、バグ修正や機能追加等の保守を容易にするという文脈で語られることが多いように思いますが、テストケースの数を減らせるというご利益もあるわけです。

状態遷移とテストケース

「状態遷移表　＝　テストケース一覧」となることは、よく知られています。クラスやオブジェクト単位の状態遷移は、xUnit等でのテスト自動化もやり易いところです。

見逃しやすいのが、アプリケーションソフト全体でも考え方は同じということです。
まず、入力されるイベントが、

• 画面のボタンクリック
• 他のシステムからのメッセージ
• etc...

になるかわるだけですね。 
出力されるアクションは

• 画面へのメッセージ表示
• ファイルへの書き出し
• etc...

ですね。
後は、入力 と 状態の組み合わせで、結果がどうなるかを示せば、漏れの無いテストケースが出来上がるというわけです。


実際は、その状態の洗い出しが難しいわけです。ひとまず入力と状態を分けて考えることで、この難しい状態の洗い出しに集中しやすくなります。