テストしやすいRailsコード【株式会社ライトコード】

はじめに

Railsで開発を進めていてると、最初は快適だったのに機能が増えるに連れてテストが書きづらくなり、修正が怖くなるようなことはないでしょうか？
この記事では、「テストしやすいRailsコード」とは何かを考えつつ、テストファーストの視点から設計を見直すためのヒントを紹介します。

なぜ「テストしやすさ」が重要なのか？

Railsは開発スピードに強みがありますが、適切な設計をしないと、テストが困難な肥大化したコードが生まれやすいという弱点もあります。
一方でテストファーストという視点を持つと、以下のようなメリットがあります。

自然と責務が明確なコードになる
フレームワーク依存を避けやすくなる
コードが疎結合で再利用しやすくなる

テストしづらいコードの例

def create

  @user = User.new(user_params)

  if @user.save

    NotifierMailer.welcom(@user).deliver_now

    redirect_to dashboard_path

    

  else

    render :new

  end

end

このコードでは以下の問題があります

DB保存とメール送信という、複数の責務が1つのメソッドに詰め込まれています。
NotifierMailerのような外部依存が直接呼ばれている
単体テストをしようとしても、コントローラーのテストでしか確認できません

改善する

1. コントローラの責務を限定する

テストしやすいコードとするには、「コントローラを薄く保つ」ことです。
ビジネスロジックはServiceクラスなどに分離させることでコントローラを薄くすることができます。

def create

  result = RegisterUserService.call(user_params)



  if result.success?

    redirect_to dashboard_path

  else

    @user = result.user

    render :new

  end

end

2. 副作用のある処理を注入可能にする

外部サービスの呼び出しは、依存性注入(DI)を活用すると、テストしやすくなります。
以下のように、キーワード引数にNotifierMailerを渡すことで、テスト時にNotiferMailerをスタブやモックに置き換えやすく、クラスの中で何を使っているのかが明示的になります。
スタブやモックに置き換えることで実際にメールが送られることもなく、結果的に副作用のないテストが可能になります

class  RegisterUserService

  def self.call(params, mailer: NotifierMailer)

    user = User.new(params)

    

    if user.save

      mailer.welcome(user).deliver_later

      OpenStruct.new(success?: true)

    else

      OpenStruct.new(success?: false, user: user)

    end

  end

end

テストコード例

class DummyMailer

  def self.welcome(user)

    OpenStruct.new(deliver_now: true)

  end

end



it 'メールを送信する' do

  expect {

    RegisterUserService.call({ name: "test", email: "test@example.com" }, mailer: DummyMailer)

  }.not_to raise_error

end