Spring Bootで登録画面を作るとき、入力チェックを付けて保存できれば完成、とは限りません。エラー文は読めるか。入力し直さずに修正できるか。画面とAPIで同じ業務ルールを守れるか。テストで何を確かめればよいか。実務では、そこまでが一つの改修です。
このガイドは、Javaのクラス・メソッドを読み、Spring BootのControllerを触ったことがある人向けです。フォームの入力から、エラー表示、Serviceへの受け渡し、MockMvcでの確認までを、既存の記事で順に追えるよう整理しました。
このガイドのゴール
「動きました」で終わらせず、どんな入力を受け、失敗したら何を返し、何をテストしたかを説明できること。コードの詳しい実装は各記事で扱い、ここでは読む順と確認する問いを示します。
読む順は「入力の約束→再表示→業務判断→テスト」
| 順番 | この段階で答えたい問い |
|---|---|
| 1．入力の約束 | 何をFormで受け取り、どの制約を検証する？ |
| 2．エラー時の再表示 | エラー文と入力値を、利用者にどう返す？ |
| 3．業務判断の分担 | どこまでが入力形式で、どこからが業務ルール？ |
| 4．修正の確認 | 画面・Service・HTTP応答の何をテストに残す？ |
各記事には別々の最小サンプルがあります。同じアプリを順に完成させる連載ではないため、クラス名やURLを混ぜず、各記事の確認環境と手順に合わせて試してください。主にSpring MVC＋Thymeleafを扱い、WebFluxやフロントエンド別構成の全体設計は対象外です。
1．Formの入力項目と、検証する制約を決める
最初に決めるのはアノテーションの種類ではなく、「この画面から何を受け取ってよいか」です。必須・文字数・形式を整理し、登録と更新で違う条件が本当に必要かを確認します。
- @Validと@Validatedの違い・グループ指定の使い分け：通常の検証と登録・更新の切り替えを区別します。グループを変えた結果、共通の必須制約が外れる例も確認できます。
- FormとDTOの違い・Serviceへ渡すクラスを分ける判断：画面だけの項目と業務処理に必要な値を分けます。名前だけ違うクラスを増やすのではなく、分ける理由と値の渡し方を確認します。
ここでの確認：各入力項目について「受け取る型・制約・Serviceへ渡すか」を説明できれば、次へ進めます。既存機能の改修なら、画面だけを見て決めず、Controllerが受け取るFormも照合してください。
2．入力エラーでも、利用者が修正を続けられる画面にする
チェックで止めることと、直せる画面を返すことは別です。メッセージが出ても入力値が消えれば再入力が必要ですし、値が残っても理由が分からなければ修正できません。この二つを分けて確認します。
- バリデーションメッセージが表示されない原因と直し方：BindingResultの検証結果が、Thymeleafの項目別メッセージへ届くまでを追います。
- 入力エラー後にFormの値・selectの選択が消える原因：入力値、選択状態、選択肢、エラー文が再表示HTMLに残っているかを確かめます。
ここでの確認：必須項目を一つ空にして送信し、それ以外の入力値を保持したまま修正できるかを見ます。正常入力だけでなく、失敗した後の画面も改修の成果物に含めてください。
3．ControllerとServiceで、入力形式と業務ルールを分ける
必須やメール形式を満たしていても、「既に登録されているメールだから受け付けられない」という判断は残ります。画面とAPIの両方に同じ判定を書き始めたら、置き場所を見直すタイミングです。
入力チェックが重複するときのControllerとServiceの分け方では、同じ重複判定を共有しつつ、HTMLには項目エラー、JSON APIには409を返す例を扱います。業務判断を共通にすることと、返し方まで同じにすることを分けて読んでください。
ここでの確認：形式エラーと業務エラーで、誰が判断し、誰が利用者へ返すかを説明します。この記事の最小サンプルは実DBの同時登録まで保証するものではありません。一意制約や競合時の扱いは別途必要です。
4．MockMvcで「通ったか」だけでなく、返した内容を確かめる
MockMvcのPOSTが403になるなら、入力チェックより手前のSecurityで止まっている可能性があります。一方、フォームの入力エラーを画面へ返す処理は200になることもあります。数字だけを見て、すべての入力エラーを400にそろえる必要はありません。
MockMvcのPOSTが403・400になる原因と確認順で、CSRF・認証・権限・Form・JSONを切り分けます。エラーを消すためにSecurityを無効化せず、期待するリクエスト条件をそろえて確認する例です。
ここでの確認：ステータスだけでなく、エラー項目、返す画面、Serviceを呼ばない分岐も見ます。表示文言や入力値の保持は、2で紹介した各記事のHTML検証につなげてください。
Controllerへ届かず400になるときの補助記事
実装を進める途中で400になる場合は、400 Bad Requestの原因と、Controllerに値が入らないときの確認順を参照してください。送った値と例外名を照合し、必須値不足・型変換・JSON読取・Validationを区別します。MockMvc固有の準備不足を扱う4の記事とは、調べる入口が異なります。
レビューに出す前に、三つのケースを説明する
- 正常な入力：何をServiceへ渡し、どの画面・応答へ進むか。
- 形式が不正な入力：どの項目にエラーを出し、入力値をどう保持するか。
- 形式は正しいが業務上受け付けられない入力：どこで判断し、保存せずどう知らせるか。
この三つは最低限の整理であり、網羅的なテスト一覧ではありません。項目の境界値、権限、競合など、変更した仕様に応じて追加します。まずは「今回何を直し、その結果を何で確かめたか」を、実行結果と一緒に伝えられる状態にしましょう。
手元で確かめる、フォーム・入力検証サンプル
入力検証、ControllerとService、Thymeleafの再表示、MockMvcとSecurityを独立した4つのプロジェクトで確かめられます。Java 17・Maven 3.9.16で58ケースが成功しました。まず解凍したREADME.htmlで対象の記事と実行手順を確認してください。
フォーム・入力検証のサンプルをダウンロード（ZIP・約36KB）
外部DBやAPIキーは不要です。初回は依存ライブラリの取得にインターネット接続が必要です。実ブラウザー、実DB、同時実行、実ログイン・パスワード照合は検証対象外です。教材をそのまま本番の完成形として使わず、確認したい部分に絞って試してください。
基礎から補いたい場合は、ブログの本棚や各記事の参考書紹介も利用してください。先に手元の課題を試し、入力処理・設計・テストのどこを深めたいかを決めると、次に読む本を選びやすくなります。
前提と公式資料
本ガイドが中心に案内する実装例は、Java 17・Spring Boot 3.5系・Spring Framework 6.2系で確認したものです。具体的な依存関係と検証範囲は各記事に記載しています。Boot 2系のjavax.validationと、3系以降のjakarta.validationを混在させず、利用中の版と照合してください。
