プログラミングマガジン

プログラミングを中心にIT技術をできるだけわかりやすくまとめます。

  • ホーム
  • Rspec
  • 【Rspec】「サポートモジュール」での共通化、DRY原則
 
 
     
  • サーバー言語  
    • Python
    • Ruby
    • PHP
    • SQL
  •  
  • インフラ  
       
    • AWS
    •  
    • 基本
    • Git
  • Web
       
    • Web開発
    • JavaScript
    • Vue.js
    • React
  •  
  • 設計  
       
    • 実装設計
    • DB設計
  • 問い合わせ
  

【Rspec】「サポートモジュール」での共通化、DRY原則

03.20

  • miyabisan2
  • コメントを書く

この記事は2分で読めます

コードの重複をなくすシンプルな方法の一つとしてサポートモジュールがあります。特にフィーチャースペックやシステムスペックでよく使える手法(ログイン処理の共通化等)です。

前提

事前に下記ファイルが編集されている必要があります。

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フック等で処理を共通化した場合に上下に大きくスクロールしなければ読めないような場合は可読性が高いとは言えない場合があるためです。

スポンサーリンク
  • 2020 03.20
  • miyabisan2
  • コメントを書く
  • Rspec
  • Tweets Twitter
  • このエントリーをはてなブックマークに追加
  • LINEで送る

関連記事

  1. 2020 03.20

    【Rspec】「リクエストスペック」について

  2. 2021 02.07

    【Rails】「devise」のテストコードの書き方や用意すると良いテストケース

  3. 2020 03.18

    【Rspec】Capybaraについて

  4. 2019 12.30

    【Rspec】「Controller Spec(コントローラスペック)」の基本

  5. 2019 12.01

    【Rspec】バージョン、設定ファイル(.rspec)、全体像を把握する。

  6. 2019 12.01

    【Rspec】System Spec(システムスペック)の基本

  • コメント ( 0 )
  • トラックバック ( 0 )
  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。

返信をキャンセルする。

【Rspec】「リクエストスペック」について

【RSpec】「Shoulda Matchers」につ…

RETURN TOP

著者プロフィール

エンジニア歴10年で過去に業務系、Webデザイン、インフラ系なども経験あります。現在はWeb系でフロントエンド開発中心です。

詳細なプロフィールはこちら

スポンサーリンク

カテゴリー

  • Android
  • API
  • AWS
  • C++
  • CSS
  • C言語
  • DDD
  • DevOps
  • Django
  • Docker
  • Git
  • GitLab
  • GraphQL
  • Hasura
  • Java
  • JavaScript
  • Kubernetes
  • Laravel
  • linux
  • MySQL
  • Next.js
  • nginx
  • Node.js
  • NoSQL
  • Nuxt.js
  • Oracle
  • PHP
  • Python
  • React
  • Redux
  • Rspec
  • Ruby
  • Ruby on Rails
  • Sass
  • Spring Framework
  • SQL
  • TypeScript
  • Unity
  • Vue.js
  • WebRTC
  • Webサービス開発
  • Webデザイン
  • Web技術
  • インフラ
  • オブジェクト指向
  • システム開発
  • セキュリティ
  • その他
  • データベース
  • デザインパターン
  • テスト
  • ネットワーク
  • プログラミング全般
  • マイクロサービス
  • マイクロソフト系技術
  • マルチメディア
  • リファクタリング
  • 副業
  • 未分類
  • 業務知識
  • 設計
  • 関数型言語
RETURN TOP

Copyright ©  プログラミングマガジン | プライバシーポリシー