concernsに定義するモジュールでよく書かれているがいまいち何をしているのかよくわかっていなかったので調べました。
結論
単純に言えば、モジュールでのクラスメソッドの定義やそれをincludeする側でクラスメソッドとして追加する方法、クラスレベルでのメソッド呼び出しの容易な方法を提供してくれるものだと理解しました。
具体例
具体例は以下のページと同じものです。
https://api.rubyonrails.org/v6.1.4/classes/ActiveSupport/Concern.html
例えば、モジュールがincludeされたときに特定の処理を呼び出したり、モジュールのメソッドをクラスメソッドとして追加したい時、通常以下のように書きます。
module M
# https://docs.ruby-lang.org/ja/latest/method/Module/i/included.html
def self.included(mod)
# includeする側(例えばクラス)の特異メソッドとしてClassMethodsを追加する -> クラスメソッドとして呼び出せる
mod.extend ClassMethods
mod.class_eval do
before_action :xxx
end
end
module ClassMethods
# クラスメソッドを定義
end
end
ActiveSupport::Concernを利用すると以下のように書けます。
module M
extend ActiveSupport::Concern
included do
before_action :xxx
end
class_methods do
# クラスメソッドを定義
end
end
ActiveSupport::Concern内のicludedやclass_methodsなどのメソッドが面倒な記述を肩代わりしてくれ、簡潔に書けるようになります。
(extendしているのでMのクラスメソッドのように扱える)
また、モジュール間の依存関係もいい感じに整理して書けるようにしてくれます。
例えば以下の場合、HostクラスはBarモジュールをincludeしたいが、BarモジュールはFooモジュールに依存しているので、FooモジュールもHostがincludeしなければならない。
module Foo
def self.included(base)
base.class_eval do
def self.method_injected_by_foo
...
end
end
end
end
module Bar
def self.included(base)
base.method_injected_by_foo
end
end
class Host
include Foo # Hostが直接関係のないモジュールまでincludeしている
include Bar
end
Barだけincludeしようとするとエラーになる。
class Host
# include Foo
include Bar
end
==> undefined method `method_injected_by_foo' for Host:Class (NoMethodError)
ActiveSupport::Concernを使うと依存関係の記述を綺麗に整理できます。
module Foo
extend ActiveSupport::Concern
included do
def self.method_injected_by_foo
...
end
end
end
module Bar
extend ActiveSupport::Concern
include Foo
included do
self.method_injected_by_foo
end
end
class Host
include Bar
end
参考
ActiveSupport::Concernが具体的に提供してくれるもの。(ソースコード)
https://github.com/rails/rails/blob/83217025a171593547d1268651b446d3533e2019/activesupport/lib/active_support/concern.rb#L110
はじめに
単体テストコードはフリマアプリ作成時にしっかり書いたのですが、結合テストは書いていなかったのでオリジナルアプリでは書いていきたいと思います。
その中で学習したことをアウトプットとして投稿させて頂きます。
単体テストと結合テストの違い（単体テストの場合）
単体テストは機能ごとにテストを行います。
例えばuserの単体テストコードの場合
user_rspec.rb
describe 'ユーザー新規登録' do
context '登録できるとき' do
it 'nickname,email,password,company_name,profession_idが存在する場合は登録ができる' do
end
end
context '登録ができないとき' do
end
end
モデルやコントローラーの機能ごとに問題がないかバリデーションの挙動を確認します。
単体テストと結合テストの違い（結合テストの場合）
結合テストの場合はユーザーがアプリを使用する一連の流れを確認するものになります。
ホームページ → 新規登録ボタンをクリック → 新規登録フォームに入力し完了ボタンをクリック → ホームページに遷移する
この結合テストを実行するためにはSystem Specという技術を使用します。
この技術を使用するためにはCapybaraというGemが必要ですが標準で記載されているかと思われます。
ファイルの作成
実施にテストコードを記述していくためにファイルを作成します。
今回はユーザーについての結合テストコードを記述していきます。
ターミナル
rails g rspec:system users
これでファイルは作成されます。
それではexampleを整理していきます
新規登録できる場合を考えていきます。
この時のポイントは、「ユーザー目線で考える」ことです。あまり細かく考えずに、「ブラウザでどのような操作をすると、どうなるのか」を考えます。
spec>system>users_spec.rb
require 'rails_helper'
RSpec.describe "新規登録", type: :system do
before do
@user = FactoryBot.build(:user)
end
context 'ユーザーが新規登録ができる時' do
it '正しい情報を入力すればユーザー新規登録ができてトップページに移動する' do
# トップページに移動する
# トップページにサインアップページへ遷移するボタンがあることを確認する
# 新規登録ページへ移動する
# ユーザー情報を入力する
# サインアップボタンを押すとユーザーモデルのカウントが1上がることを確認する
# トップページへ遷移したことを確認する
# ログアウトボタンが表示されることを確認する
# サインアップページへ遷移するボタンや、ログインページへ遷移するボタンが表示されていないことを確認する
end
end
end
実際にはアプリを操作しながら書いていくと分かりやすいです。
次は実施にコードを書いていきます。
