いわゆる禁則処理。

「パラメタ不正や禁則に違反する入力を組み合わせ試験に用いると、組み合わせ網羅率の低下につながる。」

というのは、特にHAYST法関連の書籍や研究でよく見かける主張だ。

ここでいう禁則処理とは、句読点や記号を行頭に置かないために行末にぶら下げる処理のことではない。
ある機能への入力として禁じられた値や値の組み合わせのことだ。

たとえば、印刷機能だったら「プリンタ機種Aでは、両面印刷はサポートされていない」だとか計算機だったら「１２ケタ以上の入力は許されていない」だとかだ。

しかし、なんだか妙な話にも聞こえる。
ソフトウェアの機能というものは、入力チェックも含んだものではないのか？間違った入力に対して「そんな入力はダメだ！」というのもそのソフトウェアの機能の一部ではないのか？
だとしたら、HAYST法関連の書籍が言うとおりに、「許容されない」値やその組み合わせをテストから取り除いてしまったら、「入力チェックが正しく行われる」というソフトウェアの重要な特性が全くテストされないことになってしまう。

まあ、組み合わせテストを行う際の暗黙の了解として、「正常な出力を期待するべき組み合わせが正しく動作することを確認するのが目的」と考えるべきだろう。
で、正常な出力を期待するべき組み合わせ自体がおびただしい数にのぼる。
だから、正常な出力を確認できる様々な組み合わせを慎重に選ぶ。これがPairwiseやHAYST法のアプローチ。

ところが、パラメタ異常は一個か二個のパラメタが不正な値を取ることで、本来テストしたい機能本体の論理が全く実行されなくなってしまう。
そのテストケースは異常ではない（＝テストしたい、そのために慎重に選ばれた）パラメタ値も含んでいる。こうした異常ではない、せっかくペア網羅率が上がるように選んだパラメタ値が無駄になってしまうのだ。こうして異常な一個か二個のパラメタのためにペア網羅率が低下してしまうのだ。

より正確に言うなら、ソフトウェア全体としてみれば、ペア網羅率は低下していない。しかし、「本来テストしたいソフトウェア機能本体」に着目するとそれはぐっと低下している。

なので、「禁則違反となるような値や値の組み合わせは可能な限り取り除いてから、組み合わせテストを生成・設計しましょう」というノウハウにたどり着くわけだ。
そしてこれは「入力チェックが正しく行われる」「必要に応じてエラーを返す」という処理は別立てで考えるべきだということでもある。

さてJCUnitではどうしようか？

「禁則違反」を回避するような、テストケース集合を生成する方法を何かしら作る必要がある。
単独のパラメタが禁則違反になる場合なら、そもそもドメインから取り除いておけばよい。２値の組み合わせが禁則を犯す場合には、その組み合わせは予め網羅済みとしておけば良さそうな気がする。（このへん、以前紹介したPairwise生成アルゴリズムの内部に関わるので詳細は省略）
３値以上の組み合わせが禁則を犯す場合にはどうするべきか？レアケースとしてその場合は「已むを得ない」としてもいいような気がするが悩ましいところだ。