RuboCop設定のCapybara cop名前空間移行と`have_content`廃止対応

activeadmin/activeadmin

CapybaraのRuboCop copがCapybara/RSpec名前空間へ移行したことに伴い、.rubocop.ymlの設定を更新し、新たに警告となったhave_contenthave_textへ置き換えました。

背景

CapybaraのRuboCop拡張において、RSpec固有のcopがCapybara/RSpecサブ名前空間へ整理されました。これにより、従来のCapybara/CurrentPathExpectationCapybara/MatchStyleなどのcop名が古いものとなり、新しいCapybara/RSpec/CurrentPathExpectationCapybara/RSpec/MatchStyleへの移行が必要になっています。また、この更新にあわせてCapybara/RSpec/HaveContentという新しいcopが追加され、have_contentの使用箇所に警告を出すようになっています。

技術的な変更

.rubocop.ymlのCapybara関連cop設定が全面的に見直され、旧名称の削除・新名称への移行・新規copの追加が行われました。

主な変更点は以下のとおりです:

  • 削除された旧名称: Capybara/CurrentPathExpectationCapybara/MatchStyleCapybara/NegationMatcherCapybara/NegationMatcherAfterVisitCapybara/SpecificActionsCapybara/SpecificFinders
  • 追加された新名称: Capybara/RSpec/CurrentPathExpectationCapybara/RSpec/MatchStyleCapybara/RSpec/NegationMatcherCapybara/RSpec/NegationMatcherAfterVisitCapybara/RSpec/SpecificMatcherCapybara/RSpec/VisibilityMatcher
  • 新規追加cop: Capybara/AssertStyleCapybara/RSpec/HaveContentCapybara/RSpec/HaveSelector(既存のCapybara/RSpec/HaveSelectorは引き続き有効)

Capybara/RSpec/HaveContentの追加により既存コードにoffenseが発生したため、features/step_definitions/配下の3ファイルでhave_contenthave_textに置き換えています。

変更前:

have = is_css ? have_css(text) : have_content(text)
# ...
expect(page).to have_content text

変更後:

have = is_css ? have_css(text) : have_text(text)
# ...
expect(page).to have_text text

同様の置き換えがadditional_web_steps.rbおよびformat_steps.rbでも行われており、合計4箇所のhave_contenthave_textに変更されています。

設計判断

新しいcopはすべてEnabled: trueで登録されており、警告を抑制する方向ではなく、コードをcop準拠の書き方に修正する方針が取られています。

PRではCapybara/RSpec/HaveContentのoffenseを# rubocop:disableで無効化するのではなく、実際にコードを修正する対応が取られています。Lint設定の有効化とコードの修正を同一PRで完結させることで、設定変更が未解決のoffenseを残した状態にならないよう管理されています。

まとめ

この変更はCapybaraのcop名前空間再編に追従したメンテナンス作業であり、.rubocop.ymlの設定とテストコードの双方を一貫して更新しています。特にhave_content廃止への対応をLint設定と同時に完結させた点は、設定変更がコードベースに与える影響を最小化する実践的なアプローチです。

記事メタデータ

Generated by:
Claude Sonnet 4.6 for DiffDaily
LLM Trace:
da51d91b

この記事はAIによって自動生成されています。内容の正確性については、必ずソースコードやPRを確認してください。

品質レビュー結果

Review Status:
リトライ後承認
Review Count:
2回 (改善を経て承認)
Reviewed by:
Gemini 2.5 Pro for DiffDaily

Review Criteria:

記事構成 ✓ PASS

Title, Context, Technical Detailの存在と明確さ

リード文(総論)、背景、技術的な変更、設計判断(各論)、まとめ(結論)の3部構成が明確に守られており、非常に分かりやすい記事構成です。

カスタムMarkdown構文 ✓ PASS

シンタックスハイライト・GitHubリンク記法の正確性

ファイル名付きシンタックスハイライト(```ruby:ファイルパス)とPR番号のリンク記法が正しく使用されています。

対象読者への適合性 ✓ PASS

エンジニア向けの適切な技術レベルと表現

RuboCopやCapybaraに関する知識を前提としており、専門的なエンジニアという対象読者に適切です。冗長な説明はありません。

パラグラフ・ライティング ✓ PASS

トピックセンテンス・1段落1トピック・段落長

各セクション、各パラグラフの冒頭で要点が述べられており、トピックセンテンスが明確です。1段落1トピックの原則も守られており、可読性が高いです。

Diff内容との照合 ✓ PASS

コードブロックとDiff内容の一致

記事内で引用されているコード変更は、提供されたDiff情報と完全に一致しています。また、「合計4箇所」という言及も、Diff全体を正確に分析した結果であり、事実に即しています。

技術用語の正確性 ✓ PASS

技術用語の正確な使用

`cop`, `namespace`, `offense`, `have_content`, `have_text`といった技術用語が文脈に沿って正確に使用されています。

説明の技術的正確性 ✓ PASS

技術的主張の正確性と論理性

Capybara copの名前空間移行や`have_content`が警告対象となった背景など、技術的な説明が正確であり、提供されたDiffとPR Descriptionの内容によって裏付けられています。

事実の突合 ✓ PASS

PR情報による主張の裏付け(ハルシネーション検出)

記事内のすべての主張は、PRのDescriptionやDiffから導き出せる範囲内にあり、ハルシネーション(捏造)は一切見られません。「設計判断」のセクションも、PRの差分から読み取れる事実に基づいています。

数値・固有名詞の確認 ✓ PASS

PR番号・コミットID・バージョン等の正確性

PR番号「#9010」や、コードの変更箇所数「合計4箇所」といった数値が正確に記載されています。

タイトル・説明との一致 ✓ PASS

記事タイトル・説明とPR内容の一致

記事のタイトルは、元のPRタイトル「Update RuboCop config」よりも具体的に、変更の核心である「Capybara cop名前空間移行」と「`have_content`廃止対応」を的確に表現しており、内容との整合性が非常に高いです。

外部知識の正確性 ✓ PASS

PRに記載のない外部知識(LTS、サポート状況など)の不使用

PR情報にないバージョンのサポート状況やリリース予定などの外部知識は含まれておらず、すべての説明がPRの範囲内で完結しています。

時間表現の正確性 ✓ PASS

時間表現がPR情報と一致しているか

「移行した」「必要になっている」といった時間表現は、ライブラリの更新に伴う設定変更というPRの文脈を正確に反映しており、誤解を招く表現はありません。