おもこん

おもこんは「思いつくままにコンピュターの話し」の省略形です

徒然Ruby（２５）minitestのmockの詳細

Ruby

minitestについて連続して2回書いてきました。 「minitestはドキュメントが少ない」という人がいますが、私も同感です。 例えば、モックとスタブの説明も少ないです。 そこで、今回はmock.rbのソースコードを参考に、モックの私的ドキュメントを書いてみました。 あくまで私個人の考えであり、minitest作成者の意図とは何の関係もありませんので、あらかじめご了解ください。

デリゲータ

デリゲータ（delegator）は「委任者、委任する人」ということなので「モックに処理を委任するオブジェクト」という意味ではないかと思います。 デリゲータはモックを生成するときに、newコマンドの引数として与えます。

require 'minitest/mock'

# delegator
m = Minitest::Mock.new("Hello world")
# m is a mock
p m #=> <Minitest::Mock:0x00007f809dedab50 @delegator="Hello world", @expected_calls={}, @actual_calls={}>
# Because m (mock) uses the delegator's method, m.display is the same as "Hello.world".display
m.display #=> Hello world
print "\n"
print m+"\n" #=> Hello world\n
# Because m has its own to_s method, m.to_s is NOT "Hello world".to_s
print m, "\n" #=> <Minitest::Mock:0x00007f8130db2c08>

m.expect(:size, 1000)
print m.size, "\n" #=> 1000, the size method is defined by m.expect.
print m.length, "\n" #=> 11, which is the real length of "Hello world"
p m #=> <Minitest::Mock:0x00007f264bd96e30 @delegator="Hello world", 
    # @expected_calls={:size=>[{:retval=>1000, :args=>[], :kwargs=>{}}]},
    # @actual_calls={:size=>[{:retval=>1000, :args=>[], :kwargs=>{}}]}>
p m.verify #=> true
# m.size #=> Error: No more expects available for :size

minitest/mockを取り込んでおきます。 mには文字列オブジェクト"Hello world"をデリゲータとするモックを代入します。

  • p mでモックのインスタンス変数@delegatorに"Hello world"がセットされていることがわかる
  • displayメソッドはObjectクラスのメソッドで、自分自身を標準出力に（to_sメソッドで文字列化して）出力する
  • モックはほとんどのメソッドをundef（未定義状態にする）していて、displayメソッドも持っていない
  • そのときはモックはデリゲータのメソッドとして実行する。 したがって、m.displayは"Hello world".displayを実行し、標準出力にHello worldが出力される
  • モックは+メソッドも持っていないので、m+"\n"はデリゲータの+メソッド（"Hello world"+"\n"）を実行する
  • モックはto_sメソッドを自身のメソッドとして持っているので、m.to_sはデリゲータを使わず、自身を文字列化する

ここまでで、要するにモックはデリゲータのほとんどのメソッドを引き継いでいることが分かると思います。

モックがexpectメソッドで「みせかけのメソッド」を定義するとき、そのメソッドがデリゲータのメソッドと同一名であれば、expectの定義を優先します。 後半を見ていきましょう

  • モックmにsizeメソッドが1000を返すように、expectメソッドで定義
  • m.sizeは1000を返す。 mはデリゲータのsizeメソッド（こちらは文字数の11になる）は使わず、expectの定義を優先した
  • m.lengthではモック自身はlengthメソッドを持たないので、デリゲータの"Hello world".lengthを実行し、11を返す
  • p mでモックの内容を表示すると、@expected_callsと@actual_callsの配列要素に、expectでの定義とm.sizeの実行それぞれの返り値と引数が記録されている
  • m.verifyでモックにおけるexpectされたメソッドが実行されたのでtrueが返された
  • 最後の一行はコメントされているが、仮にコメントアウトして実行するとエラー（フェイル）になる。 これはexpectが1回で、呼び出し2回目ということで、expectされていないので実行できない、というエラー

以上の機能からするとデリゲータとモックはどういう関係なのでしょうか？

モックはデリゲータをラップする。 デリゲータのメソッドのうち、テストで用いたいメソッドだけexpectでセットし、それ以外はそのまま実行させる

つまり、モックに置き換えたい元のオブジェクトがデリゲータだと考えられます。

メソッド呼び出し時のチェック

引数のチェック

expectでは3番めの引数が、定義するメソッドのパラメータです。

モック.expect(メソッド名, 返り値, パラメータの配列)

expectで定義されたメソッドはそのメソッドの呼び出し時にチェックされます。 チェックするのは

  • expectで定義された回数より多くそのメソッドが呼び出された（No more expects available for メソッド名）
  • expectで定義されたパラメータの数とメソッド呼び出し時の引数の数が一致するか
  • expectで定義されたパラメータとメソッド呼び出し時の引数のタイプが一致するか（===または==が成り立つかどうか）。 例えばexpectでStringのパラメータを定義し、呼び出し時に"abc"が引数であれば、String==="abc"はtrueになる。 ===はClassクラスで定義されていて、引数がそのクラスのインスタンスまたはサブクラスのインスタンスならばtrueになる。 StringクラスはClassクラスのインスタンスなので===が定義されている。 なお、"abc"===Stringはfalseになる。 文字列クラスのインスタンスメソッドとして===が再定義されているためで、文字列インスタンスの===と==は同じ
# arguments
m.expect(:concat, "Hello, folks.", [String, Integer])
print m.concat("Foo", 100), "\n" #=> Hello, folks.
m.expect(:concat, "Hello, there.", [Integer])
print m.concat("abc"), "\n" #=> Error :concat called with unexpected arguments
m.expect(:concat, "Hello, there.", [String, String])
print m.concat("abc"), "\n" #=> Error :concat expects 2 arguments
  • expectメソッドによって、concatメソッドを返り値"Hello, folks."、引数は2つでタイプはStringとIntegerと定義
  • m.concat("Foo", 100)は引数の数、タイプとも定義に合っているので、返り値"Hello, folks."`が返される
  • expectメソッドによって、concatメソッドを返り値"Hello, there."、引数は1つでタイプはIntegerと定義
  • m.concat("abc")は引数の数は1つで良いが、タイプがIntegerではないのでエラーになる
  • expectメソッドによって、concatメソッドを返り値"Hello, there."、引数は2つでタイプはStringとStringと定義
  • m.concat("abc")は引数の数が2つで定義と異なるのでエラーになる

以上のように、呼び出し時の引数が定義と異なるとエラーになります。

最後の引数のハッシュオブジェクト

一般にメソッド呼び出しの最後の引数のハッシュは{}を省略できることになっています。 expectでも同様に最後のパラメータにハッシュをつけ足すことができます。

モック.expect(メソッド名, 返り値, パラメータの配列, ハッシュ)

呼び出し時にハッシュの部分が同一でなければエラーになります。

m.expect(:concat, "Hello, folks.", [String], a:10,b:20,c:30)
print m.concat("abc", a:10, b:20, c:30), "\n" #=> Hello, folks.
m.expect(:concat, "Hello, folks.", ["efg"], a:10,b:20,c:30)
print m.concat("efg", a:10, b:20, c:30), "\n" #=> Hello, folks.
  • expectメソッドによって、concatメソッドを返り値"Hello, folks."、引数は1つでタイプはString、次にハッシュの引数{a:10,b:20,c:30}が続くよう定義
  • m.concat("abc", a:10, b:20, c:30)では定義通り文字列と（定義と同一の）ハッシュを引数としているので実行され、"Hello, folks."が返される
  • expectメソッドによって、concatメソッドを返り値"Hello, folks."、引数は1つで文字列"efg"、次にハッシュの引数{a:10,b:20,c:30}が続くよう定義
  • m.concat("efg", a:10, b:20, c:30)では定義と同一の文字列、ハッシュを引数としているので実行され、"Hello, folks."が返される

モックは、予定された引数でメソッドが呼ばれるかどうかのチェックが結構厳しいです。 テストですから当然ですが。

expectメソッドにブロックをつけるケース

expectメソッドにブロックを付けることができます。 そのときは第3、4引数（引数とハッシュ）はつけません。

モック.expect(メソッド名, 返り値){|x,y,...| x=10 && y,is_a?(String) && ....}

ブロックのパラメータにはメソッド呼び出し時の引数が代入されます。 ブロックでそのメソッドチェックをします。 メソッド呼び出し時のブロックのチェックもできます。

m.expect(:concat,"Hello, there.") {|x,y| x.is_a?(String) && y.is_a?(Integer)}
print m.concat("a", 1), "\n" #=> Hello, there.
m.expect(:concat,"Hello, there.") {|x,y,&z| x.is_a?(String) && y.is_a?(Integer) && z.call(10)==100}
print m.concat("a", 1){|x| x*x}, "\n" #=> Hello, there.
p m.verify #=> true
  • ブロックにより第1引数が文字列、第2引数が整数であること定義された
  • メソッド実行時に"a"と1が渡されるので、条件を満たしており、実行され"Hello, there."が返される
  • 上記に加えてブロック（&zパラメータ）もチェックする。ブロックは10を与えられると100を返すような動作が期待される
  • m.concat("a", 1){|x| x*x}では、文字列、整数の引数、ブロックはパラメータを2乗（したがって10を100にして返す）なので定義の条件が満たされ"Hello, there."が返される

テストで確認したいことは、対象のプログラムが期待通りにメソッドを呼び出しているかどうかです。 上記の例は極めて簡単なので、引数のタイプの確認の重要性があまり感じられません。 しかし、実際のプログラムでは、引数がいくつかの計算を経て得られることも考えられ、期待通りのオブジェクトかのチェックが重要になるかもしれません。

verify

モックのverifyメソッドは、expectで設定されたメソッドがきちんと呼び出されたかを見ます。

  • expectの設定より多く呼び出したときは、呼び出し時にフェイルになります
  • expectの設定より呼び出しが少ない（0も含め）ときには、verifyメソッドでフェイルになります

以上、モックのソースコードを見て、モックの働きの詳細を紹介しました。

残念ながらminitestの詳しい解説がなかなか見つかりません。 結局ソースコードを読むしかないのか、とちょっと残念な気持ちになります。

ところで、ここまで解説してきましたが、モックがどれくらいテスト上で重要なのでしょうか？ そしてどれくらい有効に使えるのでしょうか？ プログラムの下位のパーツの代わりを期待されるモックとスタブですが、テスト用のパーツを書くほうが分かりやすいような気もします。 その2つは、やろうとしていることは同じで方法が違うだけです。 こんな考えが浮かぶのは、まだまだテストということの勉強が足りないのでしょうか。

最後に他のテストツールで有名なRspecについてひとこと触れたいと思います。 RSpecは使ったことがあり、本も呼んだことがあります。 RSpecは対象のプログラムの振る舞いを記述することにかなりの重点を置いているように思います。 テストだけではなく、そのプログラムの仕様を記述する感じです。 それがspec（specification 仕様）が名前になっている理由かもしれません。

実はminitestでもspec風の書き方ができるのです。 minitestのドキュメントサイトに少しだけですが、説明があります。 また、RSpecの書き方については書籍などを参考にしてください。