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