Test-driven development workflow in Ruby - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of a failing test in TDD

What will be the output when running this RSpec test before implementing the method?

Ruby

RSpec.describe Calculator do
  describe '#add' do
    it 'adds two numbers' do
      calc = Calculator.new
      expect(calc.add(2, 3)).to eq(5)
    end
  end
end

class Calculator
  # add method not implemented yet
end

A SyntaxError: unexpected end-of-input, expecting keyword_end

B

Failure/Error: expect(calc.add(2, 3)).to eq(5)

RSpec::Expectations::ExpectationNotMetError:
  expected: 5
       got: nil

C

Failure/Error: expect(calc.add(2, 3)).to eq(5)

NoMethodError:
  undefined method `add' for #<Calculator:0x00007f...>

D Test passed successfully with 1 example, 0 failures

💡 Hint

Think about what happens if you call a method that does not exist yet on an object.

Since the add method is not defined in Calculator, Ruby raises a NoMethodError when the test tries to call it. This causes the test to fail with that error.

🧠 Conceptual

intermediate

Purpose of writing a failing test first in TDD

Why do developers write a failing test before implementing the actual code in Test-driven development?

A To ensure the test framework is working and to define the expected behavior clearly before coding

B To speed up coding by skipping tests and writing code directly

C To make the code run faster by pre-checking errors

D To avoid writing documentation for the code

💡 Hint

Think about how TDD helps clarify requirements and verify correctness.

Writing a failing test first helps clarify what the code should do and confirms that the test setup works. It guides the implementation and ensures tests actually check the intended behavior.

❓ Predict Output

advanced

Result of running a test after implementing minimal code

Given this test and implementation, what is the test output?

Ruby

RSpec.describe Calculator do
  describe '#add' do
    it 'adds two numbers' do
      calc = Calculator.new
      expect(calc.add(2, 3)).to eq(5)
    end
  end
end

class Calculator
  def add(a, b)
    a + b
  end
end

A NoMethodError: undefined method `add' for Calculator

B 1 example, 0 failures

C SyntaxError: undefined local variable or method `a' for Calculator

D

1 example, 1 failure
Failure/Error: expect(calc.add(2, 3)).to eq(5)

RSpec::Expectations::ExpectationNotMetError:
  expected: 5
       got: 0

💡 Hint

Check if the add method returns the sum of two numbers.

The add method correctly returns the sum of a and b, so the test passes with no failures.

🔧 Debug

advanced

Identify the error in this TDD cycle code snippet

What error will this test produce when run?

Ruby

RSpec.describe Calculator do
  describe '#subtract' do
    it 'subtracts two numbers' do
      calc = Calculator.new
      expect(calc.subtract(5, 3)).to eq(2)
    end
  end
end

class Calculator
  def subtract(a, b)
    a - b
  # missing end here
end

A SyntaxError: unexpected end-of-input, expecting keyword_end

B NoMethodError: undefined method `subtract' for Calculator

C 1 example, 0 failures

D RSpec::Expectations::ExpectationNotMetError: expected 2 but got 8

💡 Hint

Look carefully at the method definition and class structure.

The subtract method is missing an 'end' keyword, causing a syntax error when Ruby tries to parse the code.

🧠 Conceptual

expert

Why refactor after tests pass in TDD?

In Test-driven development, after making a failing test pass, why is refactoring the next important step?

A To rewrite the tests to match the new code instead of the other way around

B To add more features immediately without checking existing code

C To remove all tests since the code works now

D To improve code quality and maintainability without changing behavior, ensuring tests still pass

💡 Hint

Think about the purpose of refactoring in clean code practices.

Refactoring cleans up code structure and readability while keeping behavior the same. Tests ensure no changes break functionality during this process.