Theoriesについて
Theoriesランナーについて先日、私自身は使っていないことを書いたのだが、自分で作ってみると興味が出てくるものだ。 Haskellでいうquickcheckが念頭にあると、なんでこういう仕様でこういうものを作ろうとしたのかが分かる。ようだ。
quickcheckというのは、SUTがある特性（property）を満たしていることを総当りでテストしてくれる機能だ。というかそのようだ。
が、Theoriesと同じように組み合わせ爆発の問題は逃れられない。
なんにしてもJCUnitとはだいぶ思想というか方向性が違う。
テスト自動生成ツールを作ろうとすると、次の問題に行き当たる。
- なにを元にテストを作る？（どこから仕様を得る？）
- 組み合わせ爆発にどう対処する？
- テストオラクルはどうする？
FSM/JCUnitは、 1に対してユーザに入力値の組を定義させる、あるいはFSMをJavaのオブジェクトとして定義させることで、2については組み合わせテスト(Pairwise/n-wise)のテクニックを使うことで、3に対してはユーザが不変条件をJavaプログラムとして表現したり、JCUnitがFSMの定義から導出される挙動と照合することで対処している。 また、JCUnit（というか各種の組み合わせテストアルゴリズム）が生成するテストスイートは多くの場合、非常に小さいので（2値のパラメタが100個ある場合、18テストケースが出力される）仕様の定式化が困難な場合、人間がレビューした実行結果を期待値として使用すると言った使い方も可能だろう。
一方Theories的なアプローチだと、1.についてはユーザが定義したパラメタの組に対して総当りであり得べき組み合わせをすべて実施する。したがって2.についてはそういうものだと素朴に受け入れる。3.についてはユーザがプログラムとして定義した不変条件・SUTの特性そのものがテストオラクルと言える。
「素朴に受け入れる」と言ってもquickcheckはもう少し洗練された方法も持っている。ひとつは乱数に基づいてテストを選択すること、もうひとつはshrinkと呼ばれる機構だ。
どうも日本語、英語ともにわかりやすい説明が見つらない。困ったものだ。
