RSpec テストのベストプラクティス

Ruby、Rails、RSpec テストの専門家です。

主要な原則

包括的なカバレッジ

テストは一般的なケースとエッジケースの両方をカバーする必要があり、無効な入力とエラー条件を含める必要があります。

可読性と明確性

• describe、context、it ブロックに説明的な名前を使用する
• アサーション読みやすさを向上させるために expect 構文を使用する
• テストコードは簡潔に、不要な複雑性を避ける
• 複雑なロジックを説明するコメントを含める

テストの構成

• クラス/モジュールに describe を、異なるシナリオに context を使用する
• テスト対象のオブジェクトを定義する際の繰り返しを防ぐために subject ヘルパーを使用する
• spec ディレクトリ内でソースファイルの構造をミラーリングする

テストデータ管理

• 最小限で必要なセットアップのために let と let! を活用する
• テストデータ生成には fixtures より FactoryBot ファクトリを優先する
• 各テストに必要なデータのみを作成する

テスト分離

• 各テストは独立しており、テスト間で共有状態がない必要がある
• 外部サービス (API、データベース) をモック化し、メソッドを適切にスタブする
• 過度なモック化を避ける：可能な限り実際の動作をテストする

重複の削減

• shared_examples を使用してコンテキスト間で共通の動作を共有する
• 反復的なパターンをヘルパーやカスタムマッチャーに抽出する
• 複数のスペック間で共通のセットアップに shared_context を使用する

例となる構造

RSpec.describe User, type: :model do
  subject { build(:user) }

  describe 'validations' do
    it { is_expected.to validate_presence_of(:email) }
    it { is_expected.to validate_uniqueness_of(:email) }
  end

  describe '#full_name' do
    context 'when both first and last name are present' do
      let(:user) { build(:user, first_name: 'John', last_name: 'Doe') }

      it 'returns the combined name' do
        expect(user.full_name).to eq('John Doe')
      end
    end

    context 'when last name is missing' do
      let(:user) { build(:user, first_name: 'John', last_name: nil) }

      it 'returns only the first name' do
        expect(user.full_name).to eq('John')
      end
    end
  end
end