TDD Cycle Skill

Overview

This skill guides you through the Test-Driven Development cycle:

1. RED: Write a failing test that describes desired behavior
2. GREEN: Write minimal code to pass the test
3. REFACTOR: Improve code while keeping tests green

Workflow Checklist

Copy and track progress:

TDD Progress:
- [ ] Step 1: Understand the requirement
- [ ] Step 2: Choose test type (unit/request/system)
- [ ] Step 3: Write failing spec (RED)
- [ ] Step 4: Verify spec fails correctly
- [ ] Step 5: Implement minimal code (GREEN)
- [ ] Step 6: Verify spec passes
- [ ] Step 7: Refactor if needed
- [ ] Step 8: Verify specs still pass

Step 1: Requirement Analysis

Before writing any code, understand:

• What is the expected input?
• What is the expected output/behavior?
• What are the edge cases?
• What errors should be handled?

Ask clarifying questions if requirements are ambiguous.

Step 2: Choose Test Type

Step 3: Write Failing Spec (RED)

Spec Structure

# frozen_string_literal: true

require 'rails_helper'

RSpec.describe ClassName, type: :spec_type do
  describe '#method_name' do
    subject { described_class.new(args) }

    context 'when condition is met' do
      let(:dependency) { create(:factory) }

      it 'behaves as expected' do
        expect(subject.method_name).to eq(expected_value)
      end
    end

    context 'when edge case' do
      it 'handles gracefully' do
        expect { subject.method_name }.to raise_error(SpecificError)
      end
    end
  end
end

Good Spec Characteristics

• One behavior per example: Each it block tests one thing
• Clear description: Reads like a sentence when combined with describe/context
• Minimal setup: Only create data needed for the specific test
• Fast execution: Avoid unnecessary database hits, use build over create when possible
• Independent: Tests don't depend on order or shared state

Templates

• See unit_spec.erb for model/service specs
• See request_spec.erb for API specs

Step 4: Verify Failure

Run the spec:

bundle exec rspec path/to/spec.rb --format documentation

The spec MUST fail with a clear message indicating:

• What was expected
• What was received (or that the method/class doesn't exist)
• Why it failed

Important: If the spec passes immediately, you're not doing TDD. Either:

• The behavior already exists (check if this is intentional)
• The spec is wrong (not testing what you think)

Step 5: Implement (GREEN)

Write the MINIMUM code to pass:

• No optimization yet
• No edge case handling (unless that's what you're testing)
• No refactoring
• Just make it work

# Start with the simplest thing that could work
def full_name
  "#{first_name} #{last_name}"
end

Step 6: Verify Pass

Run the spec again:

bundle exec rspec path/to/spec.rb --format documentation

It MUST pass. If it fails:

1. Read the error carefully
2. Fix the implementation (not the spec, unless the spec was wrong)
3. Run again

Step 7: Refactor

Now improve the code while keeping tests green:

Refactoring Targets

• Extract methods: Long methods → smaller focused methods
• Improve naming: Unclear names → intention-revealing names
• Remove duplication: Repeated code → shared abstractions
• Simplify logic: Complex conditionals → cleaner patterns

Refactoring Rules

1. Make ONE change at a time
2. Run specs after EACH change
3. If specs fail, undo and try different approach
4. Stop when code is clean (don't over-engineer)

Step 8: Final Verification

Run all related specs:

bundle exec rspec spec/models/user_spec.rb

All specs must pass. If any fail:

• Undo recent changes
• Try a different refactoring approach
• Consider if the failing spec reveals a real bug

Common Patterns

Testing Validations

describe 'validations' do
  it { is_expected.to validate_presence_of(:email) }
  it { is_expected.to validate_uniqueness_of(:email).case_insensitive }
  it { is_expected.to validate_length_of(:name).is_at_most(100) }
end

Testing Associations

describe 'associations' do
  it { is_expected.to belong_to(:organization) }
  it { is_expected.to have_many(:posts).dependent(:destroy) }
end

Testing Scopes

describe '.active' do
  let!(:active_user) { create(:user, status: :active) }
  let!(:inactive_user) { create(:user, status: :inactive) }

  it 'returns only active users' do
    expect(User.active).to contain_exactly(active_user)
  end
end

Testing Service Objects

describe '#call' do
  subject(:result) { described_class.new.call(params) }

  context 'with valid params' do
    let(:params) { { email: 'test@example.com' } }

    it 'returns success' do
      expect(result).to be_success
    end

    it 'creates a user' do
      expect { result }.to change(User, :count).by(1)
    end
  end

  context 'with invalid params' do
    let(:params) { { email: '' } }

    it 'returns failure' do
      expect(result).to be_failure
    end
  end
end

Anti-Patterns to Avoid

1. Testing implementation, not behavior: Test what it does, not how
2. Too many assertions: Split into separate examples
3. Brittle tests: Don't test exact error messages or timestamps
4. Slow tests: Use build over create, mock external services
5. Mystery guests: Make test data explicit, not hidden in factories