privateメソッドの例外発生テスト
メソッド単位にテストを書いていると、privateメソッド単体の試験をしたくなるときがありますが、 リフレクションを使ってテストした場合は、例外の扱いに気をつける必要があります。
というのも、リフレクション中に例外が発生した場合は、InvocationTargetExceptionに例外が包含されるからです。
例えばあるprivateメソッド中でIllegalArgumentExceptionを発生させるテストを書いたとして、
// ここまでに例外が発生するように事前準備等をしてあると仮定 try { // privateメソッドのTestTarget#testMethod(String)の実行 Method method = TestTarget.class.getDeclaredMethod("testMethod", String.class); method.setAccessible(true); method.invoke(testSuite, "test parameter"); fail("doesn't reach this code."); } catch (IllegalArgumentException ie) { assertEquals("exptected error message", ie.getMessage()); // ←到達しない }
こんな感じでしょうか。
ですが、このテストは必ず失敗します。invokeが返してくるのがInvocationTargetExceptionだからです。
テストでリフレクションを使ってメソッドに例外を発生させた場合は、getCause
で原因の例外を見る必要があります。
} catch (InvocationTargetException ie) { assertThat(ie.getCause(), is(instanceOf(IllegalArgumentException.class))); assertEquals("exptected error message", ie.getCause().getMessage()); }
こんな感じですかね。なんか意図通りにいかないなーと思ったときに思い出してもらえると私みたいに頭抱えなくて済むのではないでしょうか!
そもそもテストが必要になるくらいのメソッドがprivateでいいのか、と個人的には思います。 「本当にそれ、privateでいいの?」は、声に出して言いたい日本語であると言って・・・過言ですが、 私のレビューではわりと言ってる気がします。
One more thing...
昨日はWWDCでしたね。後半のMusic推しはだるかったですが、まさか途中でFOBの曲が流れるとは思ってもいませんでした。 FOBはまたライブ行きたいです。が、機会のあることやら・・・
しかし、Developers ConferenceであんなにMusicを推されても、Developerとしてあの場にいた人にとっては微妙かと思いますが、どうなんでしょう?Music APIでも公開されるとかならわかりますが、ただのアプリ紹介でしたしね。
まあおまけですね。Swift 2のOpen SourceとiPadのマルチタスクが個人的に熱かったです。
どさくさに紛れて音楽の話をすると、ちょうど前日に愛用しているIE80の端子が接触不良を起こすようになり、 リケーブルを考えていたところ、ちょっと時間ができたのでeイヤホンに物色に行き、 試したUniverse Proがすごくいい感じだったので即決してきました。
低音が、素晴らしいです。ベースの音を聴いている感じがすごくします。 欠点を言うなら、シュア掛けしない派にはケーブルについてる癖が邪魔というくらいでしょうか。
ということで、今日シュア掛けしない派から卒業しました。いい音には勝てなかったよ・・・