1 はじめに：なぜ「テストの使い分け」が必要なのか
Rails学習において、すべての機能にRSpec（自動テスト）を書くのが正解だと思われがちですが、実務では「テストの費用対効果」を考慮し、自動テストと目視確認を使い分けています。
今回は「商品出品機能（保存）」と「商品詳細表示機能（表示）」を比較し、エンジニアがどのような思考でテストを選択しているのかを解説します。
2 RSpecが必須な「保存機能」：データの整合性を守る
「商品出品機能」のように、ユーザーの入力をデータベースに保存するフェーズは、RSpecによる自動テストが極めて重要です。
なぜRSpec（自動化）なのか？
境界値テストの効率化: 「300円ならOK、299円ならNG」というルールを手動で何度も試すのは非効率で、ミスが発生します。
退行テスト（リグレッションテスト）: 将来、別の機能を追加した際に「知らないうちに出品機能が壊れていた」という事態を、実行ボタン一つで防げます。
DBの確実な保証: 実際に「レコードが1つ増えたか」という裏側の状態を100%保証します。
3 動画（目視）が優先される「表示機能」：UI/UXの正しさを守る
一方、今回の「商品詳細表示機能」のように、情報を整理して出すだけの機能は、ブラウザでの目視確認（動画撮影）が優先されます。
なぜ目視なのか？
条件分岐の直感的な確認: 「出品者」「購入者」「未ログイン」でボタンが切り替わる挙動は、画面で見るのが最も確実です。
デザイン崩れの検知: RSpecは「文字があるか」は見れますが、「ボタンが重なっていて押せない」といったレイアウトの致命的なミスには気づけません。
UX（ユーザー体験）の保証: 「画像がリンク切れしていないか」など、人間にしか判断できない「使い心地」を証明します。
4データの架け橋「アソシエーション」
表示機能を実装する上で欠かせないのがアソシエーション（Association）です。
アソシエーションとは
バラバラのテーブル（商品、ユーザー、カテゴリー等）を繋ぐ「見えない糸」です。これがあるおかげで、複雑なSQLを書かずに直感的なコードでデータを取り出せます。
1対多の関係 (has_many / belongs_to): 「一人のユーザーがたくさんの商品を出品する」関係。
ActiveHashとの連携: DBに保存されない固定データともアソシエーションを組むことで、ID（数字）を日本語の名称（カテゴリー名など）に変換して表示できます。
5 結論：エンジニアが持つべき「バランス感覚」
「守り（データの保存・ロジック）」はRSpecで機械的に担保。
「攻め（ユーザーに届く見た目・体験）」は目視で人間が確認。
この両輪を回すバランス感覚こそが、効率的でバグのない開発への近道です。