RSpec expectations and matchers in Ruby - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this RSpec expectation?

Consider the following RSpec test snippet. What will be the result when it runs?

Ruby

describe 'Array' do
  it 'checks if array includes 3' do
    expect([1, 2, 3, 4]).to include(3)
  end
end

A The test passes because 3 is included in the array.

B The test fails because include matcher only works with strings.

C The test raises a SyntaxError due to missing parentheses.

D The test fails because the array does not include 3.

💡 Hint

The include matcher checks if the given element is present in the collection.

The include matcher in RSpec checks if the expected element is present in the array. Since 3 is in [1, 2, 3, 4], the test passes.

❓ Predict Output

intermediate

What error does this RSpec expectation raise?

What error will this RSpec test produce when run?

Ruby

describe 'String' do
  it 'checks string length' do
    expect('hello').to have_length(5)
  end
end

A No error, test passes because 'hello' length is 5.

B SyntaxError due to incorrect matcher syntax.

C NoMethodError because have_length matcher does not exist.

D Test fails with expectation failure because length is not 5.

💡 Hint

Check if have_length is a valid RSpec matcher.

RSpec does not have a built-in matcher called have_length. The correct matcher is have_attributes(length: 5) or use expect(string.length).to eq(5).

🧠 Conceptual

advanced

Which matcher correctly tests for raising an error?

You want to test that a method call raises a ZeroDivisionError. Which RSpec expectation is correct?

A expect(1 / 0).to raise_error(ZeroDivisionError)

B expect { 1 / 0 }.to raise_error(ZeroDivisionError)

C expect { 1 / 0 }.to raise_exception('ZeroDivisionError')

D expect(1 / 0).to raise_exception(ZeroDivisionError)

💡 Hint

Use a block with expect to test for errors.

To test for errors in RSpec, you must pass a block to expect. Options B and D call the expression immediately, causing the error before expect runs. Option B uses a wrong matcher name.

❓ Predict Output

advanced

What is the value of variable 'result' after this RSpec test?

Given this RSpec test, what will be the value of 'result' after it runs?

Ruby

result = nil
RSpec.describe 'Test' do
  it 'sets result' do
    result = 10
    expect(result).to eq(10)
  end
end

A result is nil

B result is 10

C result is undefined and raises NameError

D result is 0

💡 Hint

Consider variable scope inside RSpec blocks.

The 'result' inside the it block is a different local variable than the one outside. The outer 'result' remains nil after the test runs.

🔧 Debug

expert

Why does this RSpec test fail unexpectedly?

This test is supposed to check if an array is empty, but it fails. Why?

Ruby

describe 'Array' do
  it 'is empty' do
    arr = []
    expect(arr.empty?).to be true
  end
end

A The test fails because 'be true' matcher is deprecated and should be replaced with 'be_truthy'.

B The test fails because 'arr.empty?' returns false for an empty array.

C The test fails because 'expect' requires a block when testing boolean values.

D The matcher 'be true' expects the exact object 'true', but arr.empty? returns a boolean value, causing failure.

💡 Hint

Check the difference between 'be true' and 'be_truthy' matchers.

'be true' matcher expects the exact object true (i.e., object identity). arr.empty? returns true (boolean), so it should pass. However, in some Ruby versions or RSpec configurations, subtle differences cause failures. The recommended matcher is 'be_truthy' which checks truthiness instead of object identity.

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