タイトル：
- 起きたトラブル：14個のテストが全て「赤」
Railsで商品出品機能を実装。 ローカル環境でも、Renderにデプロイした本番環境でも、ブラウザからの動作確認は完璧！手数料計算のJavaScriptも、画像アップロードも、DB保存もしっかり動いている。
「あとはテストをパスさせるだけ」と軽い気持ちでRSpecを走らせた結果……。
14 examples, 14 failures
真っ赤に染まったターミナル。 「ブラウザであんなに動いているのに、なぜテストだけ1つも通らないの？」という絶望に陥りました。
- 原因：ブラウザとテストでは「データの通り道」が違う
原因を深掘りすると、「データの通り道」が根本的に違うことがわかりました。
ブラウザ（手動テスト）: 自分が画面（View）から入力した「最新のフォームデータ」をRailsが処理する。
RSpec（自動テスト）: ブラウザを通さず、FactoryBotという「テストデータの工場」から直接データを生成しようとする。
今回の実装では、DBのカラム名変更（description → info / status_id → sales_status_idなど）を行いましたが、FactoryBot側の設計図が古い名前のままだったため、テスト実行の瞬間に「存在しない場所に値を入れようとしている！」とエラーになり、テストが現場に届く前に全滅していたのです。
- そもそも「FactoryBot」って何？
今回のエラーの犯人（であり、修正の鍵）だったのが FactoryBot です。一言でいうと、「テスト用のデータを自動生成してくれる『設計図（工場）』」です。
Railsのテストは、実行のたびにテスト用DBがリセットされます。テストの度に「ユーザーを作って、商品を作って……」とコードを書くのは大変なので、あらかじめ spec/factories に作り方を定義しておき、FactoryBot.build(:item) と呼ぶだけでデータを生成できるようにする便利なツールです。
今回は、「本編のDB（Migration）」は最新にしたのに、「工場の設計図（FactoryBot）」が古いままだったため、不整合が起きていました。
- 解決へのステップ
① FactoryBot（設計図）を最新にする
spec/factories/items.rb を開き、READMEの最新定義と同期させました。
Ruby
https://github.com/358TECH-CAMP/furima-46777/commit/a743b60984e91b551a6f8f97c08f6497acda84b9
古いカラム名のままだとデータ作成自体に失敗する
sales_status_id { 2 } # status_id から変更
info { "テスト説明" } # description から変更
② テストコード（期待値）を最新にする
RSpecはエラーメッセージの内容まで一言一句チェックします。カラム名が変わるとRailsが吐き出すメッセージも変わるため、expect の中身も修正しました。
Ruby
https://github.com/358TECH-CAMP/furima-46777/commit/f57bbbdf4fa733ec8be3c9a7b435c29f294794c7
修正前
expect(@item.errors.full_messages).to include("Description can't be blank")
修正後
expect(@item.errors.full_messages).to include("Info can't be blank")
③ テスト環境の「材料」を揃える
RSpecはPC内の物理ファイルを探しに行きます。public/images/test_image.png が存在しないために起きていた Errno::ENOENT を解決するため、ディレクトリとダミー画像を用意しました。
- まとめ：テストが教えてくれたこと
今回のトラブルを通じて、RSpecの本当の役割を学びました。
環境の独立性: ローカル/本番環境と、テスト環境はデータ作成のルートが別物。
仕様の番人: 「コードを変えたらテスト（設計図）も変える」。これを怠ると、RSpecは全力で警告してくれる。
エンジニアの安心: RSpecをオールグリーンにすることは、単なる作業ではなく「この機能は設計図通りに動く」という客観的な証明。
「目視OK」で満足せず、RSpecという「もう一人の厳しい検品官」と向き合うことで、コードの品質は一段上のステージに行けるのだと感じました。