モックは必要悪で、しないにこしたことはない - blog.8-p.info

Mockito や gomock が使いやすいせいか、単体テストというのはモックするものである、という思い込みがあるのか、人々がモックしすぎているのを時折みかける。 モックは必要悪で、しないにこしたことはない。外部の API サーバーとかはガンガン叩くわけにもいかないけれど、ファイル読み書きくらいは、実際にファイルを作ったり消したりしてしまっていい。/etc/passwd を消すとか、1GB のファイルを作るとかだと難しいかもしれないけれど、その場合でも、パスのプレフィックスを指定できるようにして、一時ディレクトリの中の etc/passwd を使うとか、ファイルサイズを指定できるようにするとか、逃げ道はいくつもある。そこを飛ばして「ファイル操作は一律モックしましょう」とか頑張りだすと辛いことになりがちだ。 モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値

[t-wada]

テスト駆動開発にはざっくりいうとモックを積極的に使う派（ロンドン学派）とあまり使わない派（デトロイト学派、古典派）がありまして、私は後者なのでほとんど使わず、このエントリに深く同意するところです

[dbr0]

「テストが通らないと思ったらモックの実装が間違っていた」みたいなことがあったので気持ちは分かる。しかしマイクロサービス化のご時世でモックなしにテストできる範囲がどんどん狭くなるしでどうしたものか…

[Songmu]

昔は「結合テスト」のハードルが高かったので、そこは差し替えられるようにしようというモチベーションが高かったというのもあるのだろう、と思っている。でそのマインドセットを引きずってしまっていることがある。

[MtAsuka]

単体と結合の区別ができていないからその結論になるのかな？単体テストはあくまでもクラス単体の検証だから依存先モジュールやDBのデータなどそれ以外の要素をモック使って切り離さないと面倒で仕方なくない？

[w1234567]

モック使わないと依存先のデータまで理解、保守しないといけないから大規模＆複数チーム開発だと現実的じゃないよ。やったとしてもテストの実行にすげー時間がかかるから自然とメンテナンスされなくなる

[s_hiiragi]

“モックの一番の問題は、本番とテストで違うコードが走ることで、これは自動テストの価値をだいぶ下げてしまう。”

[mouri45]

そりゃ、仕様が間違ってるモック作ったら意味ないでしょ。RDBだったらDBの定義である程度担保できるけど、スキーマレスなDBや外部APIの時に、モックがいらねーとか言ってらんないと思うんだけど。テスト実行環境も違う

[igrep]

自分は外部のAPIすら極力手でfakeを書くなぁ。「これこれのオブジェクトのほにゃららメソッドを呼ぶ」みたいなのがテストしたい要件じゃないと感じることが多くて

[ken39arg]

完全同意。文書にしてくれてありがたい。http経由でブラックボックスな外部サービスを叩く箇所以外はモックはしない。テストのためだけにDIしているのよく見るけどそもそもそのモックいらなく無いすか？とよく言ってる

[baronhorse]

モックしないとDIいらなくねってならないんかね

[tackman]

“テスト駆動開発にはざっくりいうとモックを積極的に使う派（ロンドン学派）とあまり使わない派（デトロイト学派、古典派）がありまして” 初めて知った、私は古典派なんだな

[mas-higa]

モックは悪だが役に立つ

[hachibeechan]

極端な例だと設計の品質が悪い上でモックしまくってなにをテストしてるのかわからなくなってるモジュールとかね…

[manhole]

"モックの一番の問題は、本番とテストで違うコードが走ること" "モックと実装が密結合してしまうことで、後々コードを変更するのが大変になる"

[yujiorama]

同じコンパイル単位の実装はモックしない方がいい

[NOV1975]

逆に考えるんだ。モックこそが仕様。／本物のほうが品質が良い、というのが幻想だったりするんだよなあ。

[iekusup]

なるほど。

[yamap_55]

そりゃそうだけど、モックなしで前提条件全部整えるのあまり意味がない気がする。結合テストという認識で、一部は自動テストに含めるけど単体テストではないかなー設計が悪いと言われればそれまでだけど。

[msh5_h]

システムが複雑になってくると「結合テストで全部いけんじゃね」は詰むので詳細な単体テスト+簡易な結合テストに落ち着くし、単体テストレベルでいうとシンプルかつ高速に動作してくれるモックは正義なんですよね。

[xKxAxKx]

うむ

[shikiarai]

自分で開発環境を決められない雑魚なのでそんな高度なことができない。

[koroharo]

“単体テストとか結合テストとかの用語にみんなが合意できる定義はない、と思う”

[hatest]

謎のSE喪黒 福造（モックろ ふくぞう）が悩めるテスターのちょっとした願望をかなえてやるが、あまりに依存した結果、その代償を引き継いだ人に負わせてトンズラする話

[yarumato]

“自動テストでは、ダミーオブジェクトは無害で、フェイクオブジェクトは最初は面倒だけど役に立つ。スタブ、スパイ、モックオブジェクトあたりは逆に簡単にはじめられるけれど最終的には後悔しがち。”

[programmablekinoko]

なぜ工業製品でモックやプロトタイプがあるかと言うと、設計と量産化が別だから。ソフトウェアは設計すなわち製造なので、最初から本番を意識して作った方が良い。

[tkmkg8m]

やたらとモックとかスタブとかしたがる同僚が一時期いて、あるメソッドのインターフェース変更が呼び出し側の自動テストで検知できずにバグってたことある

[mayumayu_nimolove]

モックって結構ハードル高いからね。他サイトを参考にした方が早くて楽。

[k2wanko]

外部に関してはどうしてもモックにしなければならないところあるけど、内部で済むところは本番に極力近い状態でテストしたい

[send]

古典派だ。必要最低限にしたい

[sippo_des]

テストについて

[taruhachi]

要はバランスおじさんの出番かな？

[nilab]

「「なるだけモックしたくない」派閥は古典派」「モックするかどうかを、やりとり (インタラクション) をテストしているのか状態をテストしているのかの違い」

[raimon49]

はい

[nunulk]

自分もモック（スタブ）は外部 API 叩くやつくらいだなぁ、あとはたまに内部のモジュールに強制的に固定値返させたいときとか

[mak_in]

良い悪いってより、向き不向きで分けてる。主となる代表的なケースはできるだけ実態に近い結合テスト的なコード書いて、枝葉の細かいケース、網羅率上げて品質高めようとする単体テスト的なケースはモック使うかな。

[synonymous]

樫の木モックは必要悪

[dalmacija]

もっと離散と境界、連続の関係が気になる人が増えるといいな

[greenbow]

モックと実装が密結合してしまうのはその通りなんだけど、本末転倒ではない気がする。うまく言語化できないけどなにか引っかかる。

[oakbow]

名前がつくってことは派閥抗争があるんだろうかw このエントリには完全同意で、内部処理でモックなんか使ってると単にカバレッジ増やすためだけの意味のないテストになってることない？