コードの重複をなくすシンプルな方法の一つとしてサポートモジュールがあります。特にフィーチャースペックやシステムスペックでよく使える手法（ログイン処理の共通化等）です。
前提
事前に下記ファイルが編集されている必要があります。
|
1 |
rspec/rails_helper.rb |
下記の処理のコメントを削除して有効化しましょう。
|
1 |
Dir[Rails.root.join('spec/support/**/*.rb')].each { |f| require f } |
サポートモジュールの作り方
モジュール側
specフォルダにsupportというディレクトリを作成して処理を記述する任意のファイル名を作成しましょう。
|
1 |
spec/support/(任意の処理)_support.rb |
処理の名前はコードを読んだ際に用途がすぐにわかる名前にするようにしましょう。
サポートモジュールの具体的な処理内容は下記のように記述します。
|
1 2 3 4 5 6 7 8 |
module [任意の処理名]Support def メソッド名(引数) end end RSpec.configure do |config| config.include [任意の処理名]Support end |
呼び出す側
|
1 2 3 4 5 |
RSpec.スペック名 "XXX", type: :スペック名 do include サポートモジュール名 メソッド名 引数 end |
参考：DRY原則とは？
「Don't repeat yourself」の略で「重複させるな」という意味です。例えば下記のようなものを重複して管理せずに一元管理せよという意味になります。
- ソースコード
- 設定ファイル
- 設定値
- スキーマファイル
- ドキュメント
この原則を守っていないと後で修正する際に複数箇所を修正することになってしまいかなりの確率で修正漏れが発生して不具合に繋がる可能性が高まります。この原則を守っている場合は保守性も上がります。
必ずしもこの原則を守れば良いというわけではない
後々改修によって微妙に違うコードが発生する場合がある。
過度の共通化は各機能の依存度が高まり密結合になってしまう。
マイクロサービスアーキテクチャの登場
モノリシックなアプリケーションの場合は確実にDRY原則を守っていけばよいと思いますが、昨今人気のマイクロサービスアーキテクチャを取り入れた場合はどうしても重複したコードが発生せざるおえなくなります。
テストコードでは必ずしもDRYが正義というわけではない。
通常のソースの場合は基本的にDRYを守っていないコードは修正した方が良いですがテストコードに関しては必ずしも悪いことではありません。
例えば、テストコードは基本的には長くなるのですが例えばRspecのbeforeフック等で処理を共通化した場合に上下に大きくスクロールしなければ読めないような場合は可読性が高いとは言えない場合があるためです。
この記事へのコメントはありません。