関数型IFを返却するメソッドのjUnitでの検証

Question

###前提・実現したいこと
関数型IFを返却するメソッドの戻り値を検証したい場合、どうしたらいいでしょうか。

###発生している問題・エラーメッセージ

以下のようなメソッドがあった場合

    public Function<String, String> sampleMethod(boolean flg) {

        if (flg) {
            return str -> str + "hoge";
        } else {
            return str -> str + "fuga";
        }

    }

引数がtrueの場合に戻り値が[ str -> str + "hoge" ]であることを検証したい場合
jUnitではどう検証を行えばいいでしょうか？
また、関数型IFに適したMathcerのライブラリなどをご存知の方がいればご教示いただきたいです。

###試したこと

    Main target = new Main();

    @Test
    public void test_sampleMethod() {

        // Exercise
        Function<String, String> actual = target.sampleMethod(true);

        // Verify
        Function<String, String> expect = str -> str + "hoge";
        assertThat(actual.apply("hoge"), is(expect.apply("hoge")));
    }

という検証をつくるとテスト自体はOKにはなるのですが、

    Main target = new Main();

    @Test
    public void test_sampleMethod() {

        // Exercise
        Function<String, String> actual = target.sampleMethod(true);

        // Verify
        Function<String, String> expect = str -> "hogehoge";
        assertThat(actual.apply("hoge"), is(expect.apply("hoge")));
    }

でもOKになってしまうため、正しい検証にはなっていません。

###補足情報(言語/FW/ツール等のバージョンなど)
java : 1.8.0_111
jUnit : 4.12

Answer 1

少々乱暴な方法ですが、
関数と関数が同じかを確かめる方法の一つに、
十分多い数、引数をランダム生成して、
全部通るか検証する方法があります。

"悪意を持った"実装者がよほど運が良くなければテスト通りません。

---

いや、特定の引数に対して変な値を返すように"悪意をもって"実装すれば高確率でテスト通りますが、
要するにテストの文面でランダム値を使うことで、
実装者に「入力としてあり得るすべての値でテスト通るようにしろ」
という意図を伝える事ができるってことです。

ただ、この程度の関数だと、質問文のコードのままで意図が十分伝わるはずので
全然問題ないことになっちゃいますがね。

---

※回答じゃないです

質問文だとexpectの方を書き換えちゃってますが、

public Function<String, String> sampleMethod(boolean flg) {

        if (flg) {
            return str -> str + "hoge";
        } else {
            return str -> str + "fuga";
        }

    }

という実装がされることを期待して

    Main target = new Main();

    @Test
    public void test_sampleMethod() {

        // Exercise
        Function<String, String> actual = target.sampleMethod(true);

        // Verify
        Function<String, String> expect = str -> str + "hoge";
        assertThat(actual.apply("hoge"), is(expect.apply("hoge")));
    }

というテストを書いたが、
これだと

public Function<String, String> sampleMethod(boolean flg) {

        if (flg) {
            return str -> "hogehoge";
        } else {
            return str -> str + "fuga";
        }

    }

みたいにいくらでも抜け道ができて困る
ということですよね?

---

余談

str -> str + "hoge"自体のテストを抜け道潰して行おうとすると
exceptで同じ関数を実装することになって意味がなくなります。
こういう場合はProperty based testというものを行います。

f(x).substring(0,x.length()).equals(x);

みたいな関数それ自体の性質を何個か作り、それをテストします。

Comments

[7tsuno]

そういうことです。もともと返却値が関数のようなものなので試験なんて出来ないんでしょうかね。

[7tsuno]

やはり返却された関数も同様に試験的なことをしないと無理ですよね。
この場合は簡潔ですが、返却された関数が複雑なメソッドの場合二重に試験を行わなければいけなくなりそうですね。

[yuba]

やることは同じでも、「二重に試験を行う」という発想をしなくてもsampleMethodは、実のところ、flag, strを取る二引数関数をカリー化したものだといえます。そうしたらsampleMethodとその戻り値をあわせて二引数関数と捉え、単に二引数関数をテストするのだと考えればそれほどおかしいこと、二重に試験をしているというわけではないと言えます。

[7tsuno]

一つの関数として考えればっていうことですね。
その考え方もありですね。勉強になります。

Answer 2

私ならこう書くかなぁ。
実際のテストでは特にこっちの方がわかりやすいとおもう。

    Main target = new Main();

    @Test
    public void test_sampleMethod() {

        // Exercise
        Function<String, String> actual = target.sampleMethod(true);

        // Verify
        assertThat(actual.apply("hoge"), is("hogehoge"));
        assertThat(actual.apply("fuga"), is("fugahoge"));
    }

---

追記

実際に近い命名をしてみました。

戻り値のFunctionはHogeを連結する関数型なので、
テストする内容はHogeが連結されていることになります。

意図が明確になると違和感がないと思います。

    Main target = new Main();

    @Test
    public void test_joinHogeOrFuga() {

        // Exercise
        Function<String, String> joinHoge = target.joinHogeOrFuga(true);

        // Verify
        assertThat(joinHoge.apply("hoge"), is("hogehoge"));
        assertThat(joinHoge.apply("fuga"), is("fugahoge"));
        // 連結をさらに強調したいなら
        assertThat(joinHoge.apply("hoge"), is("hoge" + "hoge"));
        assertThat(joinHoge.apply("fuga"), is("fuga" + "hoge"));
    }

テストは結果や意図が明確であることが大事だと思います。

Comments

[7tsuno]

やはり返却された関数をさらに試験するようにしないとだめそうですね。こちらで期待した関数とアサーションできないかと考えていたのですがそれは無理そうですよね。

[iwamoto_takaaki]

関数とアサーションする必要があるかどうかというのがポイントになりそうです。

私が例題の関数は引数によって文字列を装飾してくれるメソッドなので、装飾されていること、それが一目でわかるテストというのが大事だと思います。

もちろん境界条件などのテストでわかりずらいテストケースも必要ですが、基本のテストは、仕様の説明であるべきで、基本型でチェックを基本とすべきと考えています。

基本型にすべき理由としては、わかりやすさが一番にありますが、exceptが計算式やメソッド（この場合は式）の場合、中身はチェック対象と全く同じになるため、exceptにバグを作る可能性があります。

また、例の場合は特に、チェック対象のメソッドと同じものを作成しているので、テストしていないのと同じになってしまいます。

まあ個人的な見解ですが。。。

[7tsuno]

意味のあるメソッドであればそうですね。
一般的な場合で質問をしたかったので簡単な例を出したのですが、確かにメソッドの意味を考えてテストをするというのもひとつの方法であるかもしれませんね。

expectをまったく同じ形にしたのはこの条件のときにこの式を返すとしたかったわけです。
やはりそういう形での検証は出来なそうですね。

[iwamoto_takaaki]

できるできない以前に、メソッドのテストの場合と同じように戻ってきたFunctionのテストをすれば十分だとおもいます。メソッドと同様に複雑なFunctionはありえますから・・・

とはいえ、必要なパターンも含め、このような純粋な思考も面白く思います。

[7tsuno]

もちろん理解はしていますが、
複雑なFunctionが返ってきた場合は結局そのFunctionの試験もしなければならないのが億劫ですね。
そのメソッド単体の試験としては「複雑なFunctionが返却された」ということだけ検証できればいいと思っているので、
assertThat(actual, is(str -> すごく複雑なメソッド(str)));
のような形でできたらなあという妄想です。

[iwamoto_takaaki]

そうです。ユニットテストにすごく複雑なメソッドを実際に書くことになり、現実的ではないですよ。テストにバグを作ります。

まともな設計でまともな粒度のテストを書けば、そんな複雑なテストは不要です。逆を言えば、複雑なテストが必要になる時点で設計を間違っていると考えて問題ありません。

Answer 3

関数なので単一の値のテストではどのみち不十分ですね。だからといって沢山やる必要もないですが、こんなふうに一々書くことの手間を減らせれば充分という気がしました。

assertThat(actual.apply("foo"), is(expect.apply("foo")));
assertThat(actual.apply("bar"), is(expect.apply("bar")));
...

JUnit初心者なので何が適切かは全然自身ないですが。以下のようなマッチャーを定義してそれを使うといったアイデアが浮かびました。

<T, R> isFor(Function<T, R> function, T... values);
->
assertThat(actual.apply("hoge"), isFor(expect.apply("hoge"), "foo", "bar"));

それとも既に定義されているんでしょうか・・・もしこのようなものがなくても、値のパターンを指定するJUnitの機能が別途あった気がするのでそちらを使う方がよくて、自分でマッチャーを定義する手間をかける必要はないかも知れません・・・

Comments

[7tsuno]

マッチャーを定義して値をたくさん入れてっていうのは良さそうですね。
自動で文字列を生成してランダム文字列を指定回数分チェックとかもできたら整合率もかなり高くできそうですね。

[ozwk]

jPopulatorなんてどうでしょう

[7tsuno]

これ面白そうですね！いままで乱数で自分で作ってました...

Answer 4

Verifyで書かれている

Function<String, String> expect = str -> "hogehoge";

の期待する動き（何を入れても hogehoge が得られる）と、テスト対象の関数 ( trueのときは、入力した値に hoge を追加するので hogehoge が得られる ) が同じ値となる検証なので、
expect（期待値）の書き方次第で 検証結果がtrueとなってしまうだけです。

検証してる内容が正しくないように思えますが、いかがでしょうか。

Comments

[7tsuno]

それは分かっています。この検証だとNGなのでどう検証をすればいいのかというのが今回の質問です。