もっと知りたい！じっくりプログラミング講座（中級者編）第12回：テストコードの書き方
はじめに
さあ、第12回の講座の内容にまいりましょう。今回は「テストコードの書き方」というテーマでお話しいたします。コードを書くことに慣れてきた頃、ふと「このコード、本当に正しく動いているのかしら」という不安が頭をよぎることがございませんか。その答えを与えてくれるのが、テストコードという技術でございます。一度身につければ、開発の質と自信が格段に高まりますので、どうぞ最後までご一緒くださいませ。
サマリ
テストコードとは、自分の書いたプログラムが正しく動作するかを自動で確認する仕組みです。単体テスト・結合テストの違いを理解し、テスト駆動開発（TDD）の考え方に触れながら、読みやすく保守しやすいテストの書き方を学んでいきましょう。品質の高いコードへの第一歩です。
詳細
テストコードとは何か――その目的と価値
テストコードとは、ソースコードが期待どおりに動くかどうかを自動で検証するためのコードです。手作業で動作確認を繰り返すことは、時間もかかり、見落としも生まれやすいもの。テストコードを書いておけば、変更のたびに一瞬で検証が完了します。
また、テストコードはドキュメントの役割も果たします。「この関数はどういう入力に対してどんな出力を返すのか」が、テストを読むだけで伝わるのです。チーム開発においても、コードの意図を共有する上でとても有用です。
単体テストと結合テスト――テストの種類を整理する
テストにはいくつかの種類がありますが、まず押さえておきたいのは「単体テスト」と「結合テスト」の違いです。
単体テスト（ユニットテスト）は、関数やメソッドといった最小単位の動作を個別に検証します。外部依存を持ち込まず、純粋にそのロジックだけを確かめるのが原則です。一方、結合テストは複数のモジュールやコンポーネントが連携したときの動作を検証します。データベースやAPIとの通信を含む場合もございます。
まずは単体テストをしっかり書く習慣をつけることが、安定した開発基盤をつくる近道といえます。
テスト駆動開発（TDD）という考え方
テスト駆動開発（TDD）とは、「テストを先に書いてから実装する」という開発手法です。最初は少し戸惑うかもしれませんが、慣れると設計の質が自然と上がってまいります。
TDDの基本サイクルは「レッド・グリーン・リファクタリング」の3ステップです。まず失敗するテストを書き（レッド）、次にそのテストをパスさせる最小限の実装をし（グリーン）、最後にコードを整理します（リファクタリング）。このリズムを繰り返すことで、無駄のないシンプルな実装が生まれます。
すべての開発でTDDを厳密に適用する必要はありません。ただ、「テストのことを先に考える姿勢」は、どんな現場でも大いに役立ちます。
読みやすいテストコードを書くコツ
テストコードも、立派なコードのひとつです。後から読み返したとき、あるいは他のメンバーが読んだとき、意図が伝わる書き方を心がけましょう。
よく知られているのが「AAA（アレンジ・アクト・アサート）」という構造です。日本語にすると「準備・実行・検証」です。テスト内でこの3つの段階を明確に分けて書くだけで、ぐっと読みやすくなります。
テスト名も重要です。「test_1」「testFunction」といった曖昧な名前ではなく、「正の整数を渡したとき、合計値が正しく返る」のように、何をテストしているかが一目でわかる名前をつけることをお勧めします。テストは将来の自分へのメッセージでもございます。
モックとスタブ――外部依存を切り離す技術
テストを書いていると、データベースや外部APIへのアクセスが絡んで困ることがあります。そのときに活躍するのが「モック」と「スタブ」です。
スタブは、外部依存を「あらかじめ決まった値を返すだけのもの」に差し替える技術です。モックはそれに加えて、「その関数が正しく呼ばれたか」も検証できます。この二つを使いこなすことで、外部に依存しないクリーンな単体テストが実現します。
最初は概念が難しく感じるかもしれませんが、実際にコードで使ってみると腑に落ちる瞬間がきっと訪れます。焦らず、少しずつ試してみてくださいませ。
おわりに
テストコードは、書くことに少し手間がかかるように感じるかもしれません。けれども、それは未来の自分とチームへの、とても誠実な贈り物でございます。一度書いたテストは何度でも働いてくれる、頼もしい存在ですわ。少しずつ習慣にしていただければ、開発の景色がきっと変わってまいります。次回の第13回では「セキュリティの基本知識」をテーマにお届けいたします。どうぞお楽しみに。
