自由きままに書いていきます。Boot/Kotlinに移行しています。今回は初のKotlinの記事です。KotlinはJava完全互換を謳っているので、当然Java向けのモックライブラリであるMockitoもきちんと動くということになるはずです。実際には以下のような状況ではうまく動きません。Overflowhttp://stackoverflow.com/questions/30305217/is-it-possible-to-use-mockito-in-kotlinまずモック対象のメソッドがこんな感じだとします。ここでのポイントは引数の`String`がNon-Nullになっていることです。}}そしてモックを実行します。「特定の値が指定されたとき」であれば次の書き方ができます。string"))条件を特に指定しない場合、次の書き方ができます。.findUserByToken(Mockito.anyObject())さて、この記事にたどり着いた人ならお分かりかと思いますが、これらの5つの記法のうち、実際に動くのは最初の一つのみです。こんな例外が発生します。nullその原因はMockitoの実装にあります。MockitoのSourceを見ればわかるのですが、`any()`や`anyObject()`を呼ぶと何が起きるのかというと、1内部で条件の登録を処理する2メソッドの戻り値としては`null`を返すという具合です。String)`に行きます。問題はこのtokenはNon-NullなStringだということです。親切なKotlinは、このようなNon-Nullな引数を持つメソッドを呼び出すときに、事前に「渡す予定の」引数がnullかどうかチェックしてくれます。テストコードがKotlinのSourceからJavaのコードにコンパイルされるときに、このようなメソッド呼び出しは1引数として渡す予定の値がnullかどうかチェックする、nullなら例外を投げる2実際にメソッドを呼び出すという2段階の処理として生成されるということです。KotlinのNon-Nullの実装の機構がそうなっている、という話ですね。そのため、any()の戻り値がmockされたuserServiceのインスタンスに届く前に、Kotlinのnullチェックに引っ掛かってしまい、敢え無く例外で落ちる、ということになるわけです。解決策は、このnullチェックを何とかしてくぐり抜ければ良いということになりますが、そのための方法が、「総称型扱いでnullを渡す」というものです。この場合だと、「なぜか」上記のコンパイル時の処理で1(渡す引数のnullチェック)が省略されます。Kotlinの実装依存の解決策といえばそう、ということになりますね。落ちないuserServiceMock.findByToken(nullNotNull());※Kotlinでは「渡す予定の引数のnullチェック」と「引数としてもらった変数のnullチェック」の両方を行うので、これがmockでなければ三つとも落ちます。ここではMockitoが中身をオーバライドするので、引数としてもらった変数のチェックは実行されません。一般的な解決策としては、次のようなclassを作っておいて、Mockito.any()やMockito.eq()の代わりに使えばなんとかなります。}}なんだかすっきりしない結論ですね...。Overflowで出ていた解決策でどうして解決できるんだ??と調べてみた次第です。ポイントをまとめると、1Mockito.any()の戻り値はnullである、2<T>に対してはnullチェックをサボる、というところです。これだと、今後の実装でまた動かなくなる、ということもあり得ると思います。モックするというテスト手法は下火になりつつあるという話もあるので、モックせずにうまく書いていく、という方針をとるのも手なのかもしれません。しらすのピザコメント初めまして。mockを使って行うテスト、勉強させていたはだきます。Luigiどこにでもいるようなありふれた人間・・・という訳でもなく、かと言って怪しい宗教を信仰する変人という訳でも無い。基本的に掲載しているコード等は煮ていただいても焼いていただいても結構ですが、利用は自己責任にてお願いいします。バグ・アドバイス等もしあればよろしくお願いします。