Webpacker configuration file not found

Rails6.0を使う場合、webpackerが標準になっているので,webpackerをインストールしていない場合,以下のエラーが出ます。

Webpacker configuration file not found /app_name/config/webpacker.yml. Please run rails webpacker:install Error: No such file or directory @ rb_sysopen - /app_name/config/webpacker.yml (RuntimeError)

webpackerを使うためにはYarnが必要です。
そこでDockerfileに以下を追加してYarnをインストール必要があります。

Dockerfile

RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
RUN echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list
RUN apt-get update && apt-get install -y yarn

Yarnをインストールした後、以下でwebpackerをインストールすれば大丈夫。

docker-compose run web bundle exec rails webpacker:install

Error: Cannot render console from Allowed networks

docker compose upした時に以下のエラーがlogに出ました。

 Cannot render console from 172.20.0.1! Allowed networks: 127.0.0.1, ::1, 127.0.0.0/127.255.255.255

どうやら、アクセス元のIPアドレスが 127.0.0.1の場合だけ使えるというセキュリティがかかっているようですが、http://localhost でアクセスしても間にDockerが挟まっているため、Railsからみたときのアクセス元が127.0.0.1にならないためこのエラーが出ているようです。

ですので、以下をdevelopment.rbに追記することで、172.20.0.1をホワイトリストに登録すれば対処できます。

development.rb

 config.web_console.whitelisted_ips = '172.20.0.1'

LIKE句（演算子）を使用したあいまい検索について、完全に忘れていたため、備忘録もかねて以下にまとめます。

LIKE句（演算子）とは

SQLの検索条件に指定される文字列比較演算子である。
ちょっと難しいですが、SQLに対して、LIKE句を使用するとあいまい検索ができるようになるということです。

LIKE句（演算子）の使い方

Railsでは基本的にWhereと一緒に使用し、以下のように使います。

例

model名.where('検索するカラム名 LIKE(?)', "検索ワード")

検索の取得件数の指定方法
.limited(数)と記載しましょう

例

>>先ほどのコードと組み合わせると以下のようになります。
model名.where('検索するカラム名 LIKE(?)', '検索ワード').limited(数)

不要な情報を除外する時
.where.not(不要な情報)

例

>>先ほどのコードと組み合わせると以下のようになります。
model名.where('検索するカラム名 LIKE(?)', '検索ワード').where.not(不要な情報)

ワイルドカードについて

一部を一致させて検索したい時、以下のワイルドカードが使用できます。

ワイルドカード	意味
%	任意の0文字以上の文字列
_	任意の1文字

例

>>前に１文字だけ記載あり＋後方に０文字以上の記載あり
model名.where('検索するカラム名 LIKE(?)', '_検索ワード%').limited(数)

>>前後ともに0文字以上の記載あり
model名.where('検索するカラム名 LIKE(?)', '%検索ワード%').limited(数)

>>前後ともに1文字の記載あり
model名.where('検索するカラム名 LIKE(?)', '_検索ワード_').limited(数)

具体例

上記を活用して、user名をキーワード入力された際に、検索できるようにします。
[条件]
モデル名:User
あいまい検索機能：キーワードを含んでいればOK
検索取得件数：10件
不要な情報：current_user.id=>ログイン中のユーザーIDを除外します。

上記条件を全てコードに入れると以下のようになります。

例

User.where(['name LIKE ?', "%#{params[:keyword]}%"]).where.not(id: current_user.id).limit(10)

以上となります。
最後まで閲覧いただき、ありがとうございました。
何か修正の必要な点などございましたら、コメントもしくは編集リクエストいただけますと幸いです。

参照

【Rails入門】where likeであいまい検索！複数条件やOR条件も解説
https://www.sejuku.net/blog/71189

TODOアプリにログイン機能を実装します。

・【Rails】バリデーションを実装する
・【Rails】パーシャルを利用する

Userモデルを作成

name、email、password_digestという属性を持つUserモデルを作成します。passwordではなく、必ずpassword_digestという属性を設定してください。

$ rails g model User name:string email:string password_digest:string

$ rails db:migrate

ハッシュ化したパスワードで認証ができるようにする

パスワードを平文で保存することは危険です。ハッシュ化したパスワードをDBに保存し、ユーザーのログイン時に入力されたパスワードをハッシュ化した値と比較するようにしましょう。

bcryptを追加

ハッシュ化を行うためのgemを追加します。

/Gemfile

source 'https://rubygems.org'

gem 'rails',   '5.1.6'
gem 'bcrypt',  '3.1.12'
.
.
.

$ bundle install

Userモデルにhas_secure_passwordを追加

password_digestという属性を持つモデルにhas_secure_passwordと書き込むことで、以下の3つが可能になります。

1. セキュアにハッシュ化したパスワードを、データベース内のpassword_digestという属性に保存できるようになる。
2. 仮想的な属性passwordとpassword_confirmationが使えるようになる。また、存在性と値が一致するかどうかのバリデーションも追加される。
3. authenticateメソッドが使えるようになる (引数の文字列がパスワードと一致するとUserオブジェクトを、間違っているとfalseを返すメソッド) 。

/app/models/user.rb

class User < ApplicationRecord
  has_secure_password
end

ログイン用のダミーデータを作成

password_digestという属性がある場合、ユーザー登録時にはpassword、password_confirmationの2つの属性を登録します。

$ rails c

irb(main):001:0> User.create(name: "sampleTarou", email: "tarou@example.com", password: "hogehoge", password_confirmation: "hogehoge")

セッション管理の基盤を作成

セッションを利用してユーザーを判別する仕組みを作ります。
Sessionsコントローラを生成するときに(密かに)自動生成されるセッション用ヘルパーモジュールを利用すると、sessionメソッドが使えるようになり、セッション管理の仕組みを簡単に実装することができます。

具体的には、ログイン時に
session[:user_id] = user.idでブラウザのcookieにハッシュ化したユーザーidを保存し、ページ遷移の度に
@current_user = User.find_by(id: session[:user_id])でidを元にログイン中のユーザーの情報を取得できるようになります。

Sessionsコントローラーを作成

new、create、destroyアクションを持ったSessionsコントローラーを作成します。
viewが必要なのはログインページを表示するアクションであるnewアクションだけなので、余計なファイルを生成しないためにcreate、destroyアクションは手動で追加します。

$ rails g controller Sessions new

/app/controllers/sessions_controller.rb

class SessionsController < ApplicationController

  def new
  end

  def create
  end

  def destroy
  end
end

ルーティングを設定します。

/config/routes.rb

Rails.application.routes.draw do
  get    '/login',   to: 'sessions#new'
  post   '/login',   to: 'sessions#create'
  delete '/logout',  to: 'sessions#destroy'
.
.
end

Sessionヘルパーモジュールを読み込む

sessionメソッドを全てのページで使えるようにするために、ApplicationコントローラにSessionヘルパーモジュールを読み込みます。

/app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  protect_from_forgery with: :exception
  include SessionsHelper
end

ログインページを作成

セッションにはSessionモデルというものがなく、@taskのようなインスタンス変数に相当するものもありません。

本来form_for(@task)と書くだけで、「フォームのactionは/taskというURLへのPOSTである」と自動的に判定しますが、セッションの場合はリソースの名前とそれに対応するURLを具体的に指定する必要があります。

/app/views/sessions.new.html.erb

<h1>ログイン</h1>
<%= form_for(:session, url: login_path) do |f| %>
  <%= f.label :email %>
  <%= f.email_field :email %>
  <%= f.label :password %>
  <%= f.password_field :password %>
  <%= f.submit "Log in" %>
<% end %>

ログイン状態に応じてトップページの表示を切り分け

ログイン前はログイン画面へのリンク、ログイン後はタスク一覧とログアウトボタンが表示されるようにします。(logged_in?メソッドについては後述)

/app/views/tasks/index.html.erb

<h1>TODOアプリ</h1>
<% if logged_in? %>
  <%= render 'tasks/logged_in' %>
<% else %>
  <%= render 'tasks/not_logged_in' %>
<% end %>

/app/views/tasks/_logged_in.html.erb

<h2>タスク一覧</h2>
<table>
    <thead>
      <tr>
        <th>タスク名</th>
      </tr>
    </thead>
    <tbody>
      <% @tasks.each do |task| %>
        <tr>
          <td><%= task.title %></td>
          <td><%= link_to "編集", edit_task_path(task) %></td>
          <td><%= link_to "削除", task_path(task), method: :delete %></td>
        </tr>
      <% end %>
    </tbody>
</table>
<%= link_to "タスク追加", new_task_path %>
<%= link_to "ログアウト", logout_path, method: :delete %>

/app/views/tasks/_not_logged_in.html.erb

<p>タスクの管理ができるアプリです。まずはログインをしてください。</p>
<%= link_to "ログイン", login_path%>

セッション用ヘルパーメソッドを作成

log_inメソッド

ブラウザのcookieに、ハッシュ化したユーザーidを保存するメソッドです。

app/helpers/sessions_helper.rb

module SessionsHelper

 # 渡されたユーザーでログインする
  def log_in(user)
    session[:user_id] = user.id
  end
end

current_userメソッド

cookieに保存されたユーザーidを元に、ユーザーの情報を取得するメソッドです。

app/helpers/sessions_helper.rb

module SessionsHelper
.
.
 # 現在ログイン中のユーザーを返す (いる場合)
  def current_user
    if session[:user_id]
     #@current_user = @current_user || User.find_by(id: session[:user_id])と同じ意味
      @current_user ||= User.find_by(id: session[:user_id])
    end
  end
end

findではなくfind_byで検索をしているのは、ユーザーidが存在しなかった場合findを使うと例外が返されてしまうためです。find_byを使うとnilが返されます。

logged_in?メソッド

現在のユーザーがログインしているかどうかを判別するメソッドです。ログイン状況に応じて表示する画面を切り替えたりする処理が簡単に実装できるようになります。

app/helpers/sessions_helper.rb

module SessionsHelper
.
.
 # ユーザーがログインしていればtrue、その他ならfalseを返す
  def logged_in?
    !current_user.nil?
  end
end

log_outメソッド

ブラウザのcookieに保存されているユーザーidを削除するメソッドです。

app/helpers/sessions_helper.rb

module SessionsHelper
.
.
 # 現在のユーザーをログアウトする
  def log_out
    session.delete(:user_id)
    @current_user = nil
  end
end

ログイン、ログアウト処理を実装

createアクションを作成

ログインページから送信された情報を受け取り、ログイン処理を行うアクションです。

app/controllers/sessions_controller.rb

class SessionsController < ApplicationController
.
.
  def create
    user = User.find_by(email: params[:session][:email].downcase)
    if user && user.authenticate(params[:session][:password])
      log_in user
      redirect_to root_url
    else
      render 'new'
    end
  end
.
.

destroyアクションを作成

cookieに保存されたユーザーidを削除し、ログアウトを行うアクションです。

app/controllers/sessions_controller.rb

class SessionsController < ApplicationController
.
.
  def destroy
    log_out if logged_in?
    redirect_to root_url
  end
end

タスクをいじる前にログイン状況をチェック

タスクの表示、作成、編集、削除の前にログイン状況をチェックするように設定します。

logged_in_userアクションを作成

ログインしていないユーザーをログインページにリダイレクトするアクションを作成します。application_controllerに追加することで、全てのコントローラーで利用できるようになります。

/app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
.
.
  private
   # ログイン済みユーザーかどうか確認
    def logged_in_user
      unless logged_in?
        redirect_to login_url
      end
    end
end

before_actionを設定

コントローラーの冒頭にbefore_action :<privateアクション名>, only:[:アクション名]と書き込むことで、アクションが実行される前に、指定したprivateアクションを実行することができます。

/app/controllers/tasks_controller.rb

class TasksController < ApplicationController
  before_action :logged_in_user, only:[:create, :edit, :update, :destroy]
.
.
.

終わりに

予想以上に分量が多くなりました。今回実装した内容だと、ブラウザを閉じる度にセッションが切れてログアウトします。ブラウザを閉じてもセッションを維持する方法もあるので、またいつか他の記事でまとめたいと思います。

い　つ　も　の

うっかりミスで「あ、model名を複数形にするの忘れた！」って思ってターミナル見直したら、
まさかのrailsが補完して「s」つけてくれていたという

i$ rails g model chapter

Running via Spring preloader in process 65132
      invoke  active_record
      create    db/migrate/20191124065802_create_chapters.rb
      create    app/models/chapter.rb
      invoke    test_unit
      create      test/models/chapter_test.rb
      create      test/fixtures/chapters.yml

おわりに

こんなことまで面倒見てくれてるとは知らなかったです。
rails ありがとう！！

【基本】

deviseというgemを使えば、よくあるログイン機能を簡単に作成できます。

①

Gemfileに

Gemfile

gem 'devise'

を記述し

bundle install

を実行

その後、サーバーを再起動。

rails s

なぜなら、サーバーを起動した際にgemが反映されるからです。

②

rails g devise:install

で設定ファイルを作成。

③

rails g devise user

でモデルを作成し

rails db:migrate

を実行

自動で追記される↓

config/routes.rb

Rails.application.routes.draw do
  devise_for :users
#以下略

こいつのおかげで必要なルーティングが一気に生成され、current_userやuser_signed_in?などのヘルパーメソッドが使えるようになる。

④

rails g devise:views

でビューファイル作成。

以上！

【応用】

新規登録時にニックネームを登録できるようにする。

デフォルトで登録できる情報は、メールアドレスとパスワードの2つです。
ユーザーのニックネームも登録できるようにしたいものです。
カラムを追加する方法を見ていきましょう。

①

rails g migration AddNicknameToUsers nickname:string

でマイグレーションファイルを作成し

rails db:migrate

を実行

②

deviseでログイン機能を実装した場合のパラメーターの受け取り方は通常とは異なります。

app/controllers/application_controller.rb

 class ApplicationController < ActionController::Base
    before_action :configure_permitted_parameters, if: :devise_controller?

    def configure_permitted_parameters
      devise_parameter_sanitizer.permit(:sign_up, keys: [:nickname])
    end
  end

難しいことが書いてありますが要約すると、
nicknameカラムの情報をパラメータとしてサーバーに送信することを許可します。
ということです。

これで新規登録時に、ニックネーム・メールアドレス・パスワードの3点が登録できるようになります。

ではまた！

まずはソーセージから

エンジニアの皆さま、ソーセージとウィンナーの違いはご存知でしょうか？
ちなみに私の好きなソーセージはシャウエッセンですね。
一回沸騰したお湯で３分くらい茹でてから、醤油を垂らしながら焼くと旨味がパンパンに閉じ込められてめちゃめちゃうまいです。。。
２袋で４００円くらいなんで、ちょっと高いですけどね。

本題にもどりますね。
ソーセージとウィンナーには明確な違いがあります。

ウィンナー

羊の腸に肉(豚肉や鶏肉)を詰めたもの

ソーセージ

肉を腸に詰めた食べ物の総称

つまり、ソーセージという腸詰めの食べ物の中の種類の一つにウィンナーがあります。
ウィンナーはソーセージの一種ということですねえ。
ちなみにソーセージの種類にはウィンナーの他にも何個かあってフランクフルトとかボロニアとかありますね。

URIも一緒

URIとURLの違いも全く同じです。
WEBの技術本等を呼んでるとしばしばURIって出てきます。
「URLはよく使うしなんとなくわかるけど、、、URIはまた別物？」
別物ではないです。

URL(Uniform Resource Locator)

Web上にある、あらゆるファイルがWeb上のどの位置にあるのかを表したもの

URI（Uniform Resource Identifier)

Web上にある、あらゆるファイルを認識するための識別子の総称

つまりURLはWEBにあるサイトとかホームページとかの住所みたいなものですね。
例)https://qiita.com
一方URIはURL等を含むファイル識別子のこと全般を指します。親玉みたいなものですね。
URL=住所,URI=親玉と覚えておきましょう！！！

ではURIにはURL以外にどんな識別子があるのでしょう？
URNって聞いたことがありますか？

URN（Uniform Resource Name）

Web上にある、ファイルの名前のこと
ここでいう名前というのはそのファイル自体の名前ではなくて、いわばシリアルナンバーみたいなものですね。
例)urn:isbn:35488317990
あまり馴染みがありませんよね。
基本的にはユーザーの目に入ることはあまりない識別子なので当然です。
「まあこんなものがあるんだなあ」程度に覚えておいてください。

一つ問題

「WEBページのアドレスはURLですか？URIですか？」
ここまで呼んでくださった皆さまならわかりますね。

答えは「どっちも正解」です！！
しかし、本当は
「http:(もしくはhttps:)」はURI側のパーツで、URLには含まれない」ので、厳密にはURIと呼ぶのが適切でしょう。
(賛否両論あるらしいです、、、)
まあ技術者と話す時にはURIといったほうが無難そうですね。

ソーセージ食べたくなってきた。

結論、
URI=ソーセージ
URL=ウィンナー
と覚えましょう！！！！

明日の朝はシャウエッセンで決まりだなあ

はじめに

これからRSpecを導入しようとされている方の中で、

• テストに対する抵抗感をなくしたい
• まずは簡単なテストの書き方を知りたい

という方向けに書きました。

RSpecの超基本文法とそれを使ったテストの例を以下4つの視点で１つずつ掲載しています。

1. Model
2. Controller
3. View
4. Routing

参考になれば幸いです。

【参考にさせて頂いた記事】
使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita
使えるRSpec入門・その2「使用頻度の高いマッチャを使いこなす」 - Qiita
使えるRSpec入門・その4「どんなブラウザ操作も自由自在！逆引きCapybara大辞典」 - Qiita
Ruby on Rails のテストフレームワーク RSpec 事始め - Qiita

この記事が役に立つ方

• RSpecでテストを書いたことがない方

この記事のメリット

• RSpecへの抵抗感がなくなる

環境

• OS: macOS Catalina 10.15.1
• シェル: zsh
• Ruby: 2.6.5
• Rails: 5.2.3
• RSpec: 3.9.0

【事前準備】

今回はscaffoldを使ったアプリケーションを例にしますので、３ステップで事前準備をしておきましょう。

1. scaffoldでアプリケーションを作成しておく

$ rails g scaffold user name:string email:string

2. RSpecをインストールし、テスト用ファイルを作成する

Gemfile

group :development, :test do
  gem `rspec-rails`
end

↓

$ bundle install

↓

$ rails g rspec:install

3.テストの実行方法の把握

$ rspec

上記で全テストが走りますので、テストを書いたら走らせてみましょう。

次に基本文法を見ていきます。

基本文法

require 'rails_helper'

RSpec.describe テスト対象, テストの種類 do
  describe 'テスト対象' do
    it '期待する内容を言葉で書く' do
      期待する動作をコードで書く
    end
  end
end

※実際は他にcontext、beforeなども使いますが、本記事では超シンプルなテストを例にします。

基本文法だけ見てもよく分からないと思いますので、さっと目を通して以下具体例に移りましょう。

具体例

MVC+Routingそれぞれに対し、１つずつ超シンプルなテストを書いて試していきます。

それぞれ、動作するテストのみ記載していますので、自分でいじってみて失敗するかどうかも確認するほうが良いと思います。

1.Model

バリデーションが正しく動作するかをテストしたい

Userモデルに以下のようなバリデーションがかかっていて、それをテストしたいとします。

models/user.rb

class User < ApplicationRecord
  with_options presence: true do
    validates :name
    validates :email
  end
end

では、テストを書いてみましょう。
最初に以下コマンドを実行し、テストの雛形を作成しましょう。

$ rails g rspec:models user

spec/models/user_spec.rb
が出来ているはずなので、以下のように記述して下さい。

spec/models/user_spec.rb

require 'rails_helper'

RSpec.describe User, type: :model do
  describe 'Userモデルのバリデーションテスト' do
    it 'nameとemailに値があれば有効' do
      user = User.new(
       name: "name",
       email: "sample@example.com"
      )
      expect(user).to be_valid
    end
  end
end

【解説】

User, type: :modelでUser Modelのテストであることを明示。

userに適当な名前とメールアドレスを指定してUserモデルから新規インスタンスを作成し、それをbe_validというマッチャで有効かどうかを判定しています。

---

2.Controller

indexアクションで正常にページが表示されるかテストしたい

正常にページが表示されるかはHTTPレスポンスが200であると言い換えることが出来ます。

テストを書いてみましょう。
まず先程と同様、以下コマンドを実行します。

$ rails g rspec:request users

「あれ？request? controllerじゃないの？」と思いますよね。

実は、Rails5以降はcontroller_specが非推奨となっています。

controller_specでも書けるのですが、controller関連はrequest_specで記載するのが良いようです。
詳細は下記リンクより。

RSpec 3.5 がリリースされました！

では戻ります。

先程のコマンドで
spec/request/users_spec.rb
が出来ているので以下のように記述して下さい。

spec/request/users_spec.rb

require 'rails_helper'

RSpec.describe "Users", type: :request do
  describe "GET /users" do
    it "HTTPレスポンスが200になる" do
      get users_path
      expect(response).to have_http_status(200)
    end
  end
end

【解説】

"Users", type: :requestと指定することでUsersのrequest_specであることを明示。

getリクエストでusers_path(/users)を指定し、それに対するHTTPレスポンスがresponseに入ります。

そのresponseに対してhave_http_statusというマッチャで200と等しいかを確認しています。

---

3.View

<h1>タグ内が正しく表示されるかをテストする

app/views/users/index.html.erb

<h1>Users</h1>

index/html/erbにはこんなh1タグが記載されています。

このh1タグ内に表示されている内容が正しく表示されているかをテストしてみましょう。

まずはテスト用のファイルを以下のように作成します。

$ rails g rspec:view users index

spec/views/users/index.html.erb_spec.rb
が出来ているので、以下のように記述して下さい。

spec/views/users/index.html.erb_spec.rb

require 'rails_helper'

RSpec.describe "users/index", type: :view do
  describe 'index.html.erbのテスト' do
    it 'h1タグ内にUsersが表示されているかどうか' do
      visit users_path
      expect(page).to have_selector('h1', text: 'Users')
    end
  end
end

【解説】

users/indexのviewのテストであることを最初に明示。

visitの後にusers_pathを指定することでindex.html.erbにアクセス。

expect(page)で今いるページを明示、have_selectorというマッチャで'h1'にUsersが表示されているかをテストしています。
...

※実は上記テストはうまくいきません。

騙したようで申し訳ありません。テストを実行したら、

NoMethodError: undefined method 'visit'

というエラーが出ませんでしたか？
実は自分もここで手間取りました。

ググるとかなり沢山記事が出てくるので、良くあるエラーなんだと思います。

原因はgemcapybaraがRSpecに読み込まれていないことです。

visitはcapybaraの中で定義されているDSL（ドメイン指定言語）のため、読み込むために設定を追加しなければいけません。

spec/spec_helper.rb
を開いて以下のように２行追記して下さい。

spec/spec_helper.rb

...略

require 'capybara/rspec' # ここに追記

RSpec.configure do |config|

config.include Capybara::DSL # ここに追記

...略

end

この設定で読み込まれるCapybara::DSLで定義されているDSL一覧は以下で確認することができます。

もし他にNoMethodErrorが出たら参考にしてみるのも良いかもしれません。

capybara cheat sheet · GitHub

うまくいったら次に進みましょう。

---

4.Routing

ページのルーティングが正しいかをテストする

最後はルーティングです。

createアクションに対してルーティングがうまくいっているかテストをしてみましょう。

テスト用のファイルはジェネレータを使わなくても作成出来るので、
今回は、手入力でファイルを作成します。

spec/routing/users_routing_spec.rb
を新規作成し、以下のように記述して下さい。

spec/routing/users_routing_spec.rb

require 'rails_helper'

RSpec.describe "routes for Users", type: :routing do
  describe 'ルーティングのテスト' do
    it 'createアクションのルーティング' do
      expect(post("/users")).to route_to("users#create")
    end
  end
end

【解説】

Usersのroutingについてのテストであることを明示。

/usersにPOSTしたら usersコントローラーのcreateアクションが動くことをテストしています。

おわりに

いかがでしたでしょうか？

超基本的な内容ではありますが、書くことに対しての苦手意識が少しで減ればいいなと思います。

私も書きながら調べていましたが、検索でヒットする内容には古い情報が多く、苦労しました。

今後も以下最新情報を参照しつつ勉強していこうと思います
RSpec Rails 3-9 - RSpec Rails - RSpec - Relish

参考にさせて頂いたサイト（いつもありがとうございます）

使えるRSpec入門・その1「RSpecの基本的な構文や便利な機能を理解する」 - Qiita
使えるRSpec入門・その2「使用頻度の高いマッチャを使いこなす」 - Qiita

使えるRSpec入門・その4「どんなブラウザ操作も自由自在！逆引きCapybara大辞典」 - Qiita
Ruby on Rails のテストフレームワーク RSpec 事始め - Qiita
全国のSeleniumer必読 - Qiita
undefined method `visit’ when using RSpec and Capybara in rails
capybara cheat sheet · GitHub

FactoryBotとCarrierWaveを使ってRSpecに画像ファイルアップロードのテストを通す

備忘録

FactoryBotとCarrierWaveを使ってRSpecに画像ファイルアップロードのテストを通す方法

環境

ruby 2.6.3
rails 5.2.3
carrierwave
FactoryBot-rails

1.spec内にfixturesディレクトリを作成

2.model内のimageuplorderの記述があるか確認

3.FactoryBot内でpictureアップローダを呼び出す

factories/feed.rb

FactoryBot.define do
  factory :feed do
    title { 'タイトル' }
    content { '投稿内容'}
    picture { Rack::Test::UploadedFile.new(File.join(Rails.root, 'spec/fixtures/rspec_test.png')) }
    user
  end
end

参考にしたサイト

RSpecに画像ファイルアップロードのテストを通す

すべてのerbファイルをhamlファイルに変換する便利なコマンドを紹介します。

gemを追加

gem 'haml-rails'
gem 'erb2haml'

を追加

bundle installもお忘れなく。

魔法のコマンド

rails haml:replace_erbs

これでいけると思います。
僕がはじめて成功した時は小躍りしました。

ではまた！

概要

遷移元のテキストボックスに入力した内容を、遷移先の画面に表示します。

画面イメージ

遷移元

遷移先

プログラム：共通

ルーティングを設定します。
moveアクションが遷移するアクションです。
indexアクションで遷移元で入力された値を受け取ります。
:nameがパラメーターで、入力された値が入っています。

routes.rb

Rails.application.routes.draw do
  post 'move' => 'home#move'
  get  'second/:name' => 'second#index'
end

プログラム：遷移元

form_tag内にアクション名「move」を設定し、
text_field_tagのパラメーターを「name」にします。
これで、button_toで生成されたbuttonを押下すると、
遷移する際に、テキストボックスに入力された値を渡すことができます。

遷移元.html.erb

<h3>画面１</h3>
<div>
  <%= form_tag("move")do %>
    <%= text_field_tag "name"%>
    <%= button_to 'Button'%>
  <% end %>
</div>

controller内では、redirect_toで遷移先のパスと、
テキストボックスで入力された値をパスに入力し、遷移させます。

遷移元_controller.rb

class HomeController < ApplicationController
  def top
  end
  def move
    redirect_to("/second/#{params[:name]}");
  end
end

プログラム：遷移先

変数名「@name」に代入されている値を表示しています。

遷移先.html.erb

<h3>画面２</h3>
名前は<%= @name %>です。

params[:name]で、遷移元で入力された値を取得し、htmlに表示する変数に代入します。

遷移先_controller.rb

class SecondController < ApplicationController
  def index
    @name = params[:name]
  end
end