RSpec expectations and matchers in Ruby - Step-by-Step Execution

Concept Flow - RSpec expectations and matchers

Start Test

↓

Set expectation

↓

Run code under test

↓

Compare actual vs expected

↓

Continue

↓

End Test

The test sets an expectation, runs code, compares actual and expected results, then passes or fails.

Execution Sample

Ruby

expect(5 + 3).to eq(8)
expect('ruby').to include('rub')
expect([1,2,3]).not_to be_empty

This code checks if 5+3 equals 8, if 'ruby' includes 'rub', and if the array is not empty.

Execution Table

Step	Expectation	Actual Value	Matcher	Result	Pass/Fail
1	expect(5 + 3).to eq(8)	8	eq(8)	8 == 8	Pass
2	expect('ruby').to include('rub')	'ruby'	include('rub')	'ruby' includes 'rub'	Pass
3	expect([1,2,3]).not_to be_empty	[1,2,3]	not_to be_empty	Array is not empty	Pass

💡 All expectations passed, test completes successfully.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
actual_value	nil	8	'ruby'	[1,2,3]	[1,2,3]
expectation_result	nil	Pass	Pass	Pass	Pass

Key Moments - 2 Insights

Why does expect(5 + 3).to eq(8) pass even though 5 + 3 is an expression?

The expression 5 + 3 is evaluated first to 8, then compared to 8 using eq matcher, so it passes as shown in execution_table step 1.

What does 'not_to be_empty' mean in the third expectation?

'not_to be_empty' checks that the array is NOT empty. Since [1,2,3] has elements, it passes as shown in step 3.

Visual Quiz - 3 Questions

Look at the execution table, what is the actual value checked in step 2?

A 8

B 'ruby'

C 'rub'

D [1,2,3]

💡 Hint

Check the 'Actual Value' column in execution_table row 2.

At which step does the matcher check that the array is not empty?

A Step 1

B Step 2

C Step 3

D None

💡 Hint

Look at the 'Matcher' column in execution_table for step 3.

If expect(5 + 3).to eq(9) was used instead, what would happen in the execution table?

A Step 1 would show Fail

B Step 1 would show Pass

C Step 2 would show Fail

D No change

💡 Hint

Compare actual value 8 with expected 9 in step 1's 'Result' column.

Concept Snapshot

RSpec expectations check if code results match what we want.
Use expect(actual).to matcher(expected) for positive checks.
Use expect(actual).not_to matcher for negative checks.
Common matchers: eq, include, be_empty.
Tests pass if actual matches expected, else fail.

Full Transcript

RSpec expectations and matchers let us write tests that check if code behaves as expected. We write expect statements with actual values and matchers to compare them. For example, expect(5 + 3).to eq(8) checks if 5 plus 3 equals 8. The test runs the code, compares actual and expected, and passes or fails accordingly. Matchers like eq check equality, include checks if a string contains a substring, and be_empty checks if a collection is empty. Using not_to reverses the check. The execution table shows each step's actual value, matcher used, and result. This helps beginners see how tests run step-by-step.

Practice

1. What does the RSpec matcher expect(value).to eq(5) check for?

easy

A. It checks if value is less than 5.

B. It checks if value is greater than 5.

C. It checks if value is not equal to 5.

D. It checks if value is equal to 5.

Solution

1. Step 1: Understand the eq matcher

   The eq matcher tests for equality between the expected and actual values.

2. Step 2: Analyze the expectation

   expect(value).to eq(5) means the test expects value to be exactly 5.

3. Final Answer:

   It checks if value is equal to 5. -> Option D

4. Quick Check:

   eq matcher = equality check [OK]

Hint: Remember eq means exact equality check [OK]

Common Mistakes:

• Confusing eq with greater_than or less_than
• Thinking eq checks for inequality
• Mixing up expect().to and expect().not_to

2. Which of the following is the correct syntax to check that an array includes the number 3 in RSpec?

easy

A. expect(array).to has(3)

B. expect(array).to include(3)

C. expect(array).to contains(3)

D. expect(array).to has_key(3)

Solution

1. Step 1: Identify the correct matcher for inclusion

   The include matcher checks if a collection contains a specific element.

2. Step 2: Match syntax with RSpec standards

   expect(array).to include(3) is the correct syntax to check if 3 is in the array.

3. Final Answer:

   expect(array).to include(3) -> Option B

4. Quick Check:

   include matcher = check element presence [OK]

Hint: Use include to check if collection has an element [OK]

Common Mistakes:

• Using has or contains which are not valid RSpec matchers
• Using has_key which is for hashes, not arrays
• Forgetting to use expect().to syntax

3. What will be the output of this RSpec test snippet?

describe 'Number test' do
  it 'checks if number is odd' do
    number = 7
    expect(number.odd?).to be true
  end
end

medium

A. The test passes because 7 is odd.

B. The test fails because 7 is not odd.

C. SyntaxError due to incorrect matcher usage.

D. The test passes but warns about deprecated syntax.

Solution

1. Step 1: Understand the code logic

   The variable number is set to 7, which is an odd number.

2. Step 2: Analyze the expectation

   expect(number.odd?).to be true checks if number.odd? returns true, which it does for 7.

3. Final Answer:

   The test passes because 7 is odd. -> Option A

4. Quick Check:

   odd? returns true for odd numbers [OK]

Hint: odd? returns true for odd numbers, expect that [OK]

Common Mistakes:

• Assuming 7 is even
• Confusing be true with eq true
• Thinking syntax is wrong here

4. Identify the error in this RSpec expectation:

expect(user.name).to eq nil

medium

A. Should use not_to eq nil to check for nil.

B. Missing parentheses around eq(nil).

C. Should use be_nil matcher instead of eq nil.

D. No error; the syntax is correct.

Solution

1. Step 1: Understand nil checking in RSpec

   While eq nil works, the preferred matcher for nil is be_nil for clarity and style.

2. Step 2: Identify best practice

   Using expect(user.name).to be_nil is clearer and idiomatic in RSpec.

3. Final Answer:

   Should use be_nil matcher instead of eq nil. -> Option C

4. Quick Check:

   Use be_nil for nil checks [OK]

Hint: Use be_nil matcher for nil checks, not eq nil [OK]

Common Mistakes:

• Thinking eq nil is a syntax error
• Adding unnecessary parentheses
• Using not_to eq nil to check for nil

5. You want to test that a method calculate returns a value greater than 10 but less than 20. Which RSpec expectation correctly checks this?

hard

A. expect(calculate).to satisfy { |v| v > 10 && v < 20 }

B. expect(calculate).to be > 10 and be < 20

C. expect(calculate).to be_between(10, 20).exclusive

D. expect(calculate).to be_between(11, 19).inclusive

Solution

1. Step 1: Understand the range requirement

   The value must be greater than 10 and less than 20, excluding 10 and 20 themselves.

2. Step 2: Analyze each option

   expect(calculate).to be > 10 and be < 20: expect(calculate).to be > 10 and be < 20 is invalid syntax; correct chaining uses (be > 10).and(be < 20).
   Options C and D: be_between is not a built-in RSpec matcher.
   expect(calculate).to satisfy { |v| v > 10 && v < 20 }: expect(calculate).to satisfy { |v| v > 10 && v < 20 } correctly checks the condition using a standard flexible matcher.

3. Step 3: Choose the best matcher

   expect(calculate).to satisfy { |v| v > 10 && v < 20 } is the correct and explicit choice using standard RSpec.

4. Final Answer:

   expect(calculate).to satisfy { |v| v > 10 && v < 20 } -> Option A

5. Quick Check:

   satisfy matcher = custom condition check [OK]

Hint: Use satisfy with block for complex conditions [OK]

Common Mistakes:

• Using non-standard be_between matcher
• Trying to chain matchers with 'and' incorrectly
• Ignoring boundary conditions in range checks