Ruby

別々のブラウザから複数のユーザがログインするような状況を再現したintegration testを実装しようとするときなど、 ユーザごとにセッションが必要になるなどして、 1つのテスト内で複数のセッションが必要になることがあります。

Ruby on Railsのintegration testでは、 標準でこのような複数のセッションを用いるテストに対応しており、 公式ドキュメントの中では、ActionDispatch::IntegrationTestのAPIドキュメントに説明があります。

複数のセッションを用いたintegration testの例

公式情報は上述のAPIドキュメントをご覧いただければと思いますが、一応こちらでも簡単な例を使ってintegration testで複数のセッションを用いる方法をご紹介します。

ここではテスト内容として、ログインしているユーザが列挙されるページをテストすることを想定してテストコードを考えます。 具体的には、ユーザ1がログインするとこのページにユーザ1が現れ、 続けてユーザ2がログインすると今度はユーザ1とユーザ2の両方がページに現れることを確認します。

シンプルにopen_session()でセッションを作って用いる場合の例

複数のセッションを用いる場合に鍵となるメソッドは、open_session()です。 このメソッドはセッションのオブジェクト返しますので、必要なセッションの回数分呼び出せば、必要な数のセッションが作成出来ます。 セッションを複数作成したら、各セッションのオブジェクトのインスタンスメソッドとしてget()やassert_response()を呼び出すことで、 セッションを指定してアクションやアサーションを実行できます。

以下にサンプルコードを示します。

require "test_helper"

class MultipleSessionTest < ActionDispatch::IntegrationTest

  test "login users page" do
    user1 = users(:one)
    user2 = users(:two)

    sess1 = open_session
    sess2 = open_session

    sess1.get login_path
    sess1.assert_response :success
    sess1.post login_path,
               params: { {email: user1.email,
                          password: user1.password} }
    sess1.assert_response :found
    sess1.assert_redirected_to root_path
    sess1.follow_redirect!

    sess1.get login_users_path
    sess1.assert_response :success
    assert_match /@#{user1.username}/, sess1.response.body
    assert_no_match /@#{user2.username}/, sess1.response.body

    sess2.get login_path
    sess2.assert_response :success
    sess2.post login_path,
               params: { {email: user2.email,
                          password: user2.password} }
    sess2.assert_response :found
    sess2.assert_redirected_to root_path
    sess2.follow_redirect!

    sess1.get login_users_path
    sess1.assert_response :success
    assert_match /@#{user1.username}/, sess1.response.body
    assert_match /@#{user2.username}/, sess1.response.body
  end
end

繰り返される処理をDSLのメソッドにまとめる例

上述のシンプルな例を見てみると、ログイン処理などで、対象とするセッションは異なるものの、ほぼ同じ処理が繰り返されていることが分かります。 こういった繰り返される処理は、特定のテストで用いるセッションのDSL (Domain-Specific Language) としてまとめることが出来ます。

以下のテストコードは、テストの手順や内容は上述のシンプルな例と同じですが、今度はこのDSLを用いてコードの繰り返しを排除したものになっています。なお、テストコードの読みやすさの観点でも、こちらの例の方が良くなっているのではないでしょうか。

require "test_helper"

class MultipleSessionWithDSLTest < ActionDispatch::IntegrationTest

  test "login users page" do
    user1 = users(:one)
    user2 = users(:two)

    sess1 = open_session_with_dsl
    sess2 = open_session_with_dsl

    sess1.login(user1)

    sess1.get_login_users
    assert_match /@#{user1.username}/, sess1.response.body
    assert_no_match /@#{user2.username}/, sess1.response.body

    sess2.login(user2)

    sess1.get_login_users
    assert_match /@#{user1.username}/, sess1.response.body
    assert_match /@#{user2.username}/, sess1.response.body
  end

  private

    module CustomDsl

      def login(user)
        get login_path
        assert_response :success
        post login_path,
               params: { {email: user.email,
                          password: user.password} }
        assert_response :found
        assert_redirected_to root_path
        follow_redirect!
      end

      def get_login_users
        get login_users_path
        assert_response :success
      end
    end

    def open_session_with_dsl
      open_session do |sess|
        sess.extend(CustomDsl)
      end
    end
end

railsの各バージョンについて、セキュリティアップデートが行われる期限（End-of-Life）は以下の通りです。

• 8.0.x - 2026/11/07
• 7.2.x - 2026/08/09
• 7.1.x - 2025/10/01
• 7.0.x - 2025/04/01

6.1.xは、以下の通りサポートが終了しています。

• 6.1.x - 2024/10/1

なお、railsのサポート期間に関するより詳細な情報については本家のメンテナンス・ポリシーを参照してください。

meta-tagsのv2.21.0で'truncate_on_natural_separator'の設定が追加されました。この設定を利用することで、スペース文字のところでの切り詰めを回避できるようになりました。このことを上のコメントに反映しました。

こちらの記事によると、activerecordでlastを使った場合、指定したorderを逆にして"LIMIT 1"とするSQLが発行されるそうです。

一方で、firstを使った場合、指定したorderはそのままで"LIMIT 1"とするSQLとなるので、railsのコードとSQLの対応関係が分かりやすくなります。

したがって、lastよりもfirstを使った方が実装とSQLが揃って可読性が上がるということがこの記事で主張されていました。 ご参考まで。

2023/12/25にcommonmarker v1.0.0がリリースされました。 それから4ヶ月以上が経過していますが、v1.xを採用せずにv0.xに留まっているライブラリやプロジェクトが多いように見受けられます。

たとえば、 jekyll-commonmarkのgem指定や commonmarker-rougeのgem指定は、 2024/05/13現在ではv0.xになっています。

v0.xで出来ていた編集操作がv1.xではまだ出来ない？

commonmarkerにMarkdownを入力して、出力されたHTMLをそのまま使う分には現在のv1.xで十分でしょう。 しかし、スタイル変更やJavaScriptによる機能付与などで、出力されるHTMLを多少変更したいことがあります。 v0.xではこういうときに使えるものとして、任意のHTMLを挿入する方法があったのですが、少なくともこのv0.xの方法はv1.xでは出来なくなったようです。

Pluginの活用か何かで、v1.xでもv0.xと同じように、出力のHTMLを部分的に好き勝手な形に編集することは出来るのでしょうか？ ご存じの方がいらっしゃいましたら、コメントをいただけると嬉しいです。

別デバイスからhttpsでrails serverにアクセスする方法

前述の方法で別デバイスからhttpでアクセスできるようになりますが、httpsでアクセスする必要がある場合には、 local-ssl-proxyを使ってhttpsをhttpに振り向けることで、httpsアクセスが可能になります。具体的な方法は以下をご覧ください。 なお別デバイスからhttpsでアクセスするには、前述のポートフォワーディングとファイアウォールの設定をhttpsのポート番号で行う必要があります。

• local-ssl-proxyを使ってhttpsでhttp://localhost:3000/へアクセスする方法

回避策が公式リポジトリのREADMEに掲載されたので、回避策のところを更新しました。

Nu validatorのコンテナイメージであるghcr.io/validator/validator:latestをローカルで走らせて、 これをw3c_validatorsのW3CValidators::NuValidatorから使う場合は、以下ようにuriを指定してnewすれば動きます。

validator = W3CValidators::NuValidator.new(:validator_uri => 'http://localhost:8888/')

ちなみに、ローカルで走らせたNu validatorに切り替えたところ実行時間がだいぶ減りましたので、w3c_validatorsが遅いと感じている方はローカル実行を試すと良いかもしれません。慣れればコンテナを走らせるのはサクッと出来ますよ。

背景

Railsのactionviewのヘルパー関数には、form_withのように、blockを活用して入れ子のHTML要素を記述できる便利なヘルパーメソッドがあります。 具体的には、以下のような記述（Railsガイドより引用）が出来るヘルパーメソッドです。

<%= form_with url: "/search", method: :get do |form| %>
  <%= form.label :query, "Search for:" %>
  <%= form.text_field :query %>
  <%= form.submit "Search" %>
<% end %>

blockを用いてHTML要素の入れ子を出力できるこのようなヘルパーメソッドの自作に関する話です。

作り方

actionviewのcaptureというヘルパーメソッドを用いると、form_withのように、blockを使ってHTML要素の入れ子を記述できるヘルパーメソッドを自作できます。

ちなみに、このcaptureは、Railsガイドを読んでも、RailsのAPIドキュメントを読んでも、いまいち使い道が分かっていなかったのですが、このような自作ヘルパーで使うというのが1つの使い道のようです。

自作ヘルパーメソッドの実装例

def some_helper(content=nil, &block)
  object_passed_to_block = 'hello, capture'
  content = capture(object_passed_to_block, &block) if block
  tag.div(content, class: 'some-class')
end

自作ヘルパーメソッドの利用例

ERBから利用

<%= some_helper do |object| %>
  <p><%= object %></p>
<% end %>

出力結果

<div class="some-class">
  <p>hello, capture</p>
</div>

Rubyのコード内から利用

some_helper do |object|
  tag.p(object)
end

出力結果

<div class="some-class"><p>hello, capture</p></div>

Rubyのコード内からblockなしで利用

some_helper('123')

出力結果

<div class="some-class">123</div>

問題

importmap-railsはv2.0.0で、「ネイティブでImport mapsに対応していないブラウザでImport mapsを機能させるためのshims」の利用を打ち切りました。 一方で、iOS 16.3以前に搭載されているSafariブラウザは、ネイティブではImport mapsに対応していません。 したがって、importmap-railsを1.x系から2.x系にバージョンアップすると、iOS 16.3以前のデバイスではJavaScriptを利用したRailsアプリが動かなくなります。 このことは、この打ち切りのプルリクエスト #216で議論されているように、開発陣に既に認識されており、認識した上での打ち切りとなっています。

なお、特にiOS 15は、2024-01-22にセキュリティアップデートが出ているAppleがサポートをまだ続けているOSであるにもかかわらず、最新の15.8.1へアップデートしたデバイスであってもRailsアプリが動かなくなるため要注意です。

（参考）iOS 15とiOS 16の状況

• 2024-01-22にセキュリティアップデートが出されているため、iOS 15以降はAppleがサポートを続けているOSであると考えられます。
• こちらのWebサイトによると、2023年8月時点の国内シェアはiOS 16が85.1％、iOS 15が10.4％となっています。
• こちらのWebサイトによると、2023年5月時点の全世界でのシェアはiOS 16が81％、iOS 15が13％となっています。

以上から、iOS 15とiOS 16のデバイスは、2024年2月現在まだまだ利用されていると言えます。

回避策

importmap-railsを用いたRails 7アプリで、iOS 16.3以前をサポートするには、 以下のようにjavascript_importmap_tagsの前にes-module-shimsを入れます。 詳細は、GitHubの公式リポジトリのREADMEの該当部分（Supporting legacy browsers such as Safari on iOS 15）を参照してください。

<script async src="https://ga.jspm.io/npm:[email protected]/dist/es-module-shims.js" data-turbo-track="reload"></script>
<%= javascript_importmap_tags %>

参考情報

• この回避策で上手く行ったという報告