Webアプリを開発する上で欠かせないのが「単体テスト」です。単体テストとは、プログラムの最小単位（関数やメソッド、モジュールなど）が正しく動作しているかを確認するテストのことです。これを怠ると、後々のバグ発見や修正コストが大きくなり、システム全体の信頼性も損なわれてしまいます。
この記事では、Webアプリの単体テストにおいてよく扱われる代表的な例として、以下の観点から具体的なテスト内容を解説します。
- 入力値のバリデーション（例：メールアドレスや電話番号の形式チェック）
- データベース処理（例：ユーザー登録・更新・削除が正しくできるか）
- 計算処理（例：料金計算や割引ロジック）
- APIとのやり取り（例：外部サービスから取得したデータの整形）
- 画面表示ロジック（例：条件に応じて表示される要素の切り替え）
実際にどのような点をテストするべきか、テストケースの具体例を交えて解説していきます。
入力値のバリデーションテスト
Webアプリでは、ユーザーからの入力を受け取るフォームが数多く存在します。特に会員登録やログイン画面では、入力された値が正しい形式かをチェックする「バリデーション」が欠かせません。
具体例：メールアドレスの形式チェック
- 正常系
- 「user@example.com」のように「@」を含む正しい形式ならエラーにならない。
- 異常系
- 「userexample.com」（@がない） → エラーになること
- 「user@@example.com」（@が2つ） → エラーになること
- 「user@.com」（ドメイン不正） → エラーになること
具体例：電話番号の形式チェック
- 正常系
- 「09012345678」のように11桁の数字で構成されている → 成功
- 異常系
- 「090-1234-5678」（ハイフンあり） → エラー
- 「abcdefghijk」 → エラー
- 桁数不足（10桁未満） → エラー
このように、正常ケースと異常ケースをセットで用意し、バリデーションが期待通りに動作するかをテストします。
データベース処理の単体テスト
Webアプリでは、ユーザー情報や商品データなどをデータベースに保存するのが一般的です。ここで重要なのは、登録・更新・削除が正しく動作するか確認することです。
具体例：ユーザー登録
- 正常系
- 新規ユーザーを登録し、データベースに正しく保存されるか確認する。
- 登録後にIDが自動採番されることをチェックする。
- 異常系
- すでに存在するメールアドレスで登録しようとするとエラーになる。
- 必須項目が未入力の場合、登録できない。
具体例：ユーザー更新
- 正常系
- ユーザー名を更新し、データベースの値が変更されていることを確認する。
- 異常系
- 存在しないユーザーIDを指定した場合、エラーが返ること。
具体例：ユーザー削除
- 正常系
- ユーザーを削除したら、データベースから該当レコードがなくなる。
- 異常系
- 存在しないユーザーIDを削除しようとした場合、エラーになる。
これらのテストは、トランザクションを利用しロールバックすることで、本番環境を汚さずに検証できます。
計算処理の単体テスト
Webアプリでは、料金計算や割引ロジックなどのビジネスルールを実装することが多いです。数値計算は一見単純ですが、境界値や例外パターンを見落とすと大きな不具合につながります。
具体例：料金計算
- 正常系
- 商品価格1000円 × 数量3 → 合計3000円になる。
- 異常系
- 数量が0の場合 → 合計0円になる。
- 数量がマイナス（-1） → エラーになる。
具体例：割引ロジック
- 正常系
- 商品価格5000円、割引率10% → 4500円になる。
- 上限割引額が設定されている場合、その上限を超えない。
- 異常系
- 割引率が100%以上 → エラーになる。
- 割引率が負の値 → エラーになる。
こうした境界値テスト（0、最大値、最小値、異常値）を網羅することで、計算処理の信頼性を高められます。
APIとのやり取りの単体テスト
近年のWebアプリは、外部のAPIサービスと連携するケースが増えています。APIの呼び出し結果を正しく処理できるかどうかも単体テストの重要な対象です。
具体例：外部サービスから天気データを取得するAPI
- 正常系
- APIが正常にレスポンスを返した場合、必要なデータ（気温、天気情報など）が正しく整形される。
- 異常系
- APIがエラー（500番台）を返した場合、アプリ側で適切に例外処理が行われる。
- レスポンスに必要な項目が欠けている場合、デフォルト値を使う、もしくはエラーを返す。
- タイムアウトした場合、リトライ処理が実行される。
このように、APIテストでは「想定通りのデータが来ない場合」を重視することが重要です。
画面表示ロジックの単体テスト
Webアプリはユーザーインターフェースの部分でも多くのロジックを持っています。条件によって表示する要素を切り替える場面では、意図通りの表示がされているか確認する必要があります。
具体例：ログイン状態による表示切り替え
- 正常系
- ログイン済みユーザーには「マイページ」リンクが表示される。
- 未ログインのユーザーには「ログイン」ボタンが表示される。
- 異常系
- セッションが切れた場合、ログイン状態であっても「ログイン」ボタンが表示される。
具体例：在庫状況による表示切り替え
- 正常系
- 在庫あり → 「購入する」ボタンが表示される。
- 在庫なし → 「在庫切れ」のラベルが表示される。
- 異常系
- 在庫数が負の値 → エラーを表示する。
このようなUIロジックは見落とされがちですが、ユーザー体験に直結するため重要です。
まとめ
単体テストは「開発者が安心してコードを書ける土台」とも言えます。入力値バリデーション、DB処理、計算処理、API連携、画面表示ロジックといった各ポイントを丁寧にテストすることで、リリース後のトラブルを大幅に減らすことができます。
この記事で紹介した具体例をベースに、プロジェクトごとに必要なテストケースを整理していけば、品質の高いWebアプリを効率的に開発できるでしょう。