MockとStubについて実際にRSpecでテスト書いてみてやっとわかったので分からなかった頃の自分でも分かるようにまとめてみた

以前、id:takihiroさんの記事（ RSpec の Mock と Stub が最初分からなかったけど、理解できたらすごい！という気持ちになった）を読んだときにはMockとStubについて「ぼや〜」としか理解できなかったんですが、実際に自分でRSpec使ってテスト書いてみたらバッチリと理解できた（つもり！）

そして理解できてからid:takihiroさんの記事を改めて読み直すとまさに自分が理解したことが書いてあった。

つまり自分に読解力が無かっただけなんですね。。。

という訳で私と同レベルの読解力難民が未だにいると信じて、自分が理解したことを当時の自分に説明するつもりで出来るだけ簡単にまとめてみました。

簡単にまとめたつもりなんですが、いかんせん長くなったので先に結論を書くと

MockとStubとはMVCでいうCの部分をテストするときに便利にしてくれる。
Mockは打ち合わせた内容をチェックするが、Stubは決めうちの返事をかえすだけ

です！

目新しいことはなにも言っていません！(強いて言えばきもい例え話が目新しい）

では早速ですが以下の順序で説明していきます。

MVCってなに？
テストって何？
Mockとは？
Stubとは？
ここまで読み終えた昔の私へ

以下私の理解と独断と偏見を交えた変な例え話ですがお付き合いいただければ幸いです。
(そして間違った解釈があれば教えてくださればうれしいです！！）

MVCって？

いきなりですが、MVCって銀行に例えちゃうと以下のような感じだと思っているんですよ。

M層: 入出金処理係の人達（仕事の鬼のような人ばかりで、すごくチェックが厳しい人です。金庫はこの人のテリトリーで何人たりともさわらせません）

V層: お客様窓口の人達（お客様対応に忙しくて入出金処理の人と話す時間もなく、また、あまり彼らのことが好きじゃないので直接話したくない人なんです。）

C層: お客様窓口の人達（V層）の部下(入出金処理の人と上司があまりにも仲が悪いから二人の間を行き来して折り合いをつけ、何とか仕事を円滑にすすめようとする苦労性の人です。つまり二人の橋渡し役ですね。長いので以下「部下」とします）

ついでに・・・

DB: 金庫ということにしときます。
データ: 主に金です。（たまに免許証とか、入出金額を記載した紙だったりとかしますが。。）

で、この会社の仕事は以下のような分業で進めています。

お客様窓口の人達の仕事

お客様から要望とそれに必要な情報を聞き出します。
また、入金や新規口座開設時はお金も受け取ります。
部下にお客様から聞いた要望と情報を、お金をほぼ丸投げして、入出金処理係の人達に口座の開設（create）や、入出金(update)、通帳記入（show）口座の閉鎖(delete)などをさせてこいと命令します。

入出金処理係の人達

お客様窓口の部下から処理を依頼され、必要な情報とお金をチェックする。
もし処理に必要な情報が足りなかったり、お金が額面と違ったりしたら「これじゃだめ！！」と部下をしかり飛ばす。
もし上記のような厳しいチェックを通ったら入出金処理や口座の開設、閉鎖処理、通帳記入などを行ってくれます。

部下

お客様窓口の上司からのお客様の要望と、情報、お金などを受け取る
お客様の要望を担当する入出金処理係の人に、上司から丸投げされた要望を処理してくださいとお願いしたり、入出金処理係の人に情報をわかりやすく伝えたり、お客様から預かったお金を渡したりします。
結果、入出金係の人に怒られたら上司に「○○という資料が足らないからだめみたいなんですけど・・」という風に何で入出金係の人に怒られたかを伝えます。

じゃあテストってなに？

この例え話の世界だと人事査定がテストに当たります。
ただ、私たちの世界と違う点は、人事査定が悪いと給料が下がるのではなく、性根からたたき直される点です。

例えば入出金係の人の査定は

どれだけ正しいチェックができるかの判断能力
その処理に漏れはないかという正確性

を主にチェックします。

これは比較的簡単にチェックできそうです。

amacouの口座に3000円入金する場合は、結果としてamacouの口座に3000円増えていることを確認する。
新規口座を開設する場合に、必要書類がすべてそろっていなかった場合は「これじゃだめ！」という判断をできるか見てみる。

っていう感じのチェックをすれいいはずです。

つまり人事査定を行う人事部の人が部下の役をして、入出金係の人がそれぞれ決められたマニュアル通りに動けるかっていうテストをしていくわけです。
（実際テスト書いてみてM層ってテストが比較的しやすいから、「業務ロジックはM層に集めてテストも厚めに書いた方がいい」という意見に納得しました）

では、お客様窓口の人の査定はというとこれはかなり難しいんじゃないかと。
お客様の立場に立ってみないとほんとに優れたお客様窓口係かは分からなそうですよね。
だからテストも最低限は定型的なチェック（ネクタイはしているかとか）はできるけど、多くの部分（お客様を不快にさせない態度とか）はお客様になったつもりで査定するしかないと思います。
（値が表示されるかとかのテストは書けるけど、結局最後は全画面目で確認していかないとだめですよね〜ってこと）

では最後に部下の人事査定を考えてみます。

部下の仕事を考えると以下の2点を査定する必要がありそうです。

上司から伝えられた要望を正しく整理して担当の入出金係に伝えられるか
入出金係の返答を踏まえて上司に正しく伝えられるか

これには上司の役を人事部がするだけでは正確な人事査定は出来ないでしょう。

例えば人事査定をするときにマニュアルを無視しまくる適当人間の入出金係がいた場合は上司に間違った報告をしても、それは部下が本当に悪かったのかが分からなくなります。

そこでMockとStubの登場です。
MockとStubはいわば入出金係の役をしてくれる臨時職員です。

もちろん臨時職員は入出金処理係ではないので、査定を行う前に、あらかじめ人事査定をする人と打ち合わせが必要です。（例えば受け答えの台本とか、入出金係役の人のチェック項目など）

Mockとは？

では上記査定の1.の場合を考えてみましょう。
ここで登場する臨時職員はMockです。

臨時職員(Mock)は以下のことを行ってくれます。

臨時職員(Mock)にきちんと要望を伝えに来たかどうかをチェック
仕事の依頼方法が台本通りだったかをチェック
上記チェックを行った後チェック内容を人事部の人に報告

人事部の人は上司の役をしたあと、臨時職員の報告を踏まえて人事査定を行うのです。
(部下が臨時職員(Mock)に依頼したあと、上司役にどういう報告をするかをチェックすることもあります）

Stubとは？

上記2.の場合を考えてみましょう。
ここで登場する臨時職員はStubです。

臨時職員(Stub)は以下のことを行ってくれます。

臨時職員(Stub)に要望を伝えにきた場合はお金を数えたりせず台本通りの返答を返す。

なんと臨時職員(Stub)はこれだけしかしてくれません。
しかし、すでに臨時職員(Mock）の力を借りて、
「この部下にこの要望をしたときは正しい臨時職員に正しい内容を伝えることができる」
というチェックは済ませているので、あとは例えば入金処理で入出金処理係に、
「ちゃんとできたよ」
と言われたのに、上司への報告で、
「やっぱりだめでした」
とか言わないことをチェックするだけでいいのです。

ここまで読み終えた昔の私へ

ここまでの話を理解できればあとは簡単！

冒頭であげたid:takihiroさんの記事（ RSpec の Mock と Stub が最初分からなかったけど、理解できたらすごい！という気持ちになった）を読めばバッチリ分かると思いますよ。

ということで長文お付き合いありがとうございました。