テストでモックを使う場面7つ｜使いすぎたときの弊害

テストを書いていると、外部との通信や時刻の取得が邪魔になる場面があります。そこで代役を置く手法が使われますが、置きすぎると本来の目的を失います。この記事では、使う場面と避ける場面を整理します。

使う場面7つ

【結論】制御できないものが対象です。

1. 外部への通信

相手の状態に左右されるため、結果が安定しません。代役を置きます。

2. 現在時刻

実行する日時によって結果が変わります。固定した値を渡してください。

3. 乱数

毎回異なる値が出るため、結果を確認できません。

4. 課金や送信を伴う処理

テストのたびに実際の請求や送信が発生しては困ります。

5. 応答の遅い処理

時間がかかる処理を含めると、テスト全体が遅くなります。

6. 再現しにくい失敗

通信の失敗や容量の不足といった状況を、意図的に作り出せます。

7. まだ完成していない部分

他の担当者が作成中の処理を、仮のもので置き換えて先に進められます。

対象	置き換える	理由
外部への通信	する	結果が安定しない
現在時刻	する	実行日で変わる
送信や課金	する	副作用が起きる
自分の計算処理	しない	確認の対象そのもの
単純なデータの保持	しない	本物で足りる

使いすぎたときの弊害

【結論】実装の写しになります。

内部構造への依存

どの処理をどの順で呼ぶかまで固定すると、整理しただけでテストが壊れます。

安心が得られない

すべてを置き換えたテストは、代役の動作を確認しているだけになります。

本物との食い違い

代役が返す値が、実際の動作と違っていることがあります。

読みにくくなる

準備の記述が長くなり、何を確認しているのか分かりにくくなります。

置き換えの種類

【結論】目的によって使い分けます。

決まった値を返すもの

問い合わせに対して固定の値を返します。最も単純な形です。

呼ばれ方を記録するもの

何回、どの引数で呼ばれたかを記録します。送信の確認に使われます。

簡易な実装で代える

本物と同じ振る舞いを簡単に実装したものを使います。記憶上のデータ保存などが該当します。

何もしないもの

呼ばれても何も起きない代役です。記録の出力などに使われます。

時刻を扱う方法

【結論】外から渡す形にします。

直接取得しない

処理の中で現在時刻を取得すると、結果が日によって変わります。

引数で渡す

時刻を引数として受け取る形にすれば、テストで固定した値を渡せます。

取得する役割を分ける

時刻を返す役割を切り出しておくと、テストで差し替えられます。

境界の確認

日付が変わる瞬間や、月末の扱いを確認できるようになります。

外部との通信を扱う

【結論】境界で切り離してください。

通信の役割を分ける

通信を担う部分と、結果を処理する部分を分けます。

処理の側を確認する

受け取った内容をどう扱うかは、代役を使って確認できます。

通信そのものの確認

実際につながるかは、別の枠組みで確認します。単体テストの範囲ではありません。

失敗の再現

接続できない状況や、想定外の応答を返す状況を作れます。

本物を使うほうがよい場合

【結論】速くて安定しているなら本物です。

単純なデータの保持

値を持つだけの処理は、本物を使うほうが読みやすくなります。

自分が書いた計算

確認したい対象そのものを置き換えては意味がありません。

軽い処理

速く終わる処理なら、置き換える理由がありません。

判断の目安

置き換えることで得られるものがあるかを考えてください。習慣で置き換えないことです。

保守しやすく書く

【結論】結果を確認してください。

呼び出しより結果

どう呼ばれたかより、何が返ったかを確認するほうが壊れにくくなります。

準備を共通化する

同じ準備が繰り返されるなら、まとめて書けるようにします。

置き換えた数を減らす

1つのテストで置き換える対象が多いなら、設計を見直す余地があります。

名前を付ける

代役にも役割の分かる名前を付けると、読みやすくなります。

チームで揃えること

【結論】方針を決めておくと迷いません。

置き換えの基準

何を置き換え、何を本物のまま使うかを決めておくと、書く人によるばらつきが減ります。

道具の統一

複数の仕組みが混在すると、読む側が混乱します。1つに揃えてください。

見直しの観点

確認する際に、置き換えが必要だったかを問う習慣をつけると、増えすぎを防げます。

記録に残す

決めた方針を文書にしておくと、後から参加した人にも伝わります。

新しく入る人への説明

既存のテストを読むだけでは、なぜ置き換えているのかが分かりません。理由をコメントか文書で補ってください。

よくある質問（FAQ）

Q1. どこまで置き換えますか

自分の制御下にないものだけです。通信、時刻、乱数が代表です。

Q2. 自分の処理も置き換えますか

確認したい対象そのものは置き換えないでください。

Q3. 置き換えが多いと何が問題ですか

実装の写しになり、整理しただけでテストが壊れます。

Q4. 時刻はどう扱いますか

処理の中で取得せず、引数で渡すか役割を切り出してください。

Q5. 通信は確認しなくてよいですか

単体テストの範囲外です。別の枠組みで確認してください。

Q6. 呼ばれ方を確認すべきですか

送信など副作用のある処理では有効です。それ以外は結果を確認するほうが壊れにくくなります。

まとめ

置き換えの対象は、自分の制御下にないものに限ってください。外部への通信、現在時刻、乱数、課金や送信を伴う処理が代表です。

自分が書いた処理まで置き換えると、テストが実装の写しになります。どの処理をどの順で呼ぶかまで固定すると、整理しただけで壊れるようになります。

時刻は処理の中で取得せず、引数で渡すか、取得する役割を切り出してください。日付が変わる瞬間や月末の扱いを確認できるようになります。

1つのテストで置き換える対象が多いなら、設計を見直す余地があります。呼び出され方より返ってきた結果を確認するほうが、変更に強いテストになります。

📱 運営の裏側・最新情報はXで発信中 → @ore_chusotsu