分かりやすいコードの書き方

第７話：テストがしやすいコード

（最終更新日：2025.4.23）

テストしやすいコードに！

コードが分かりにくい、読みにくい、変更しづらい。 そんな悩みを解決するための一つの基準が「テストしやすいコードかどうか」である。 テストがしやすいコードとは、外部に依存せず、単独で動作確認ができるコードだ。 これはそのまま「読みやすく、再利用しやすく、壊れにくいコード」にもつながる。 今回は「テストしやすさ」から見た分かりやすいコードの条件について解説する。

１.テストしやすいコードは分かりやすいコード

なぜ「テストしやすいコードは分かりやすいコードなのか」。 これは、テストしやすいコードは下記の４つの特徴を持っているからである。 つまり「テストしやすい＝構造が明快で、責任が分かれている」ということだ。 これはそのまま、可読性・保守性・拡張性の高さに直結する。

• 目的が明確 ：テストの対象がはっきりしている
• 副作用が少ない：テスト中に外部の影響を受けにくい
• 単独で動く：外部環境や状態に依存しない
• 関数が小さい： テスト範囲を限定しやすい

このことを踏まえて、次のテストしやすいコードを書くポイントを見ていこう。

２.テストしやすいコードを書くポイント

テストをしやすいコードには3つのポイントがある。 「依存性を減らす」「モックやダミーを使う」「ユニットテストが書きやすい関数設計」である。 それぞれ順番に見ていこう。

2.1 依存性を減らす（ロジックを分離する）
まずは「依存性を減らす」だ。 下記は「依存性を減らす」ための悪い例と良い例になる。 悪い例ではデータベースに接続してしまうので単体テストが難しい。

次に良い例だ。データ取得処理を外から注入できる。この方法だと、テストはモック関数を渡せる。 単体でテストがしやすくなる。

2.2 モックやダミーを使う
外部のAPIやDBに依存している関数は、テスト時に仮の関数（モック）を差し替えることで検証可能になる。 下記はモック関数の例になる。これにより、本物のデータベースを使わなくても、安全、簡単にテストができる。 user_idが123の時のユーザー名を返す。

2.3 ユニットテストが書きやすい関数の設計
関数の責任が1つだけで、入力から出力の意図が明確なら、テストは簡単だ。 下記は、その例になる。単純に価格に税率をかけて税込の値段にしている。 そして、関数自体が状態を持っていないので、テストがしやすい。

３.テストがしにくいコードとしやすいコードの比較

最後に、テストがしにくいコードとしやすいコードの比較を挙げる。 次のようにまとめられる。外部依存が少なく、責任の範囲が１つで、副作用を持たない。 再現性が高く、テストコードが書きやすいというものだ。

テストしやすい、しにくいコードの比較

項目	テストしにくいコード	テストしやすいコード
外部依存	直接DBやAPIを呼び出す	処理を外から注入できる
関数の責任	複数の処理が混在	単一の責務に絞っている
副作用	グローバル変数を変更	副作用を持たない
再現性	環境に依存して結果が変わる	常に同じ入力で同じ結果が出る
テストコード	書くのが難しい	簡単に書けてすぐ実行できる

４.まとめ

今回、テストがしやすいコードは、設計がシンプルで読みやすいことが分かった。 加えて、外部依存を避けてそれ単体で意味が成立する、テストできるようにすることが重要だ。 そのためには、モックやダミーを使うことが必要だということも分かった。 今回のようなコードを書くことを心がけることで、可読性・保守性・信頼性のすべてが上がるはずだ。

▼参考図書、サイト

 「リーダブルコード」　Dustin Boswell、Trevor Foucher　著、角 征典　訳　オライリー