Bird
Raised Fist0
Rubyprogramming~30 mins

Test-driven development workflow in Ruby - Mini Project: Build & Apply

Choose your learning style10 modes available
Test-driven development workflow
📖 Scenario: You are building a simple calculator program that adds two numbers. You will use test-driven development (TDD) to create the calculator step by step.
🎯 Goal: Create a Ruby program that adds two numbers using TDD. You will first write a test, then write the code to pass the test, and finally print the result.
📋 What You'll Learn
Create a test method named test_addition that checks if adding 2 and 3 equals 5
Create a method named add that takes two numbers and returns their sum
Call the add method with 2 and 3 and store the result in a variable named result
Print the value of result
💡 Why This Matters
🌍 Real World
Test-driven development helps programmers write reliable code by writing tests before the actual code. This reduces bugs and improves confidence.
💼 Career
Many software development jobs require knowledge of TDD to ensure code quality and maintainability.
Progress0 / 4 steps
1
Write the test method
Write a method named test_addition that uses raise to check if add(2, 3) equals 5. Use raise "Test failed" unless add(2, 3) == 5 inside the method.
Ruby
Hint

Define test_addition method and use raise with a condition that calls add(2, 3) and checks if it equals 5.

2
Create the add method
Create a method named add that takes two parameters a and b and returns their sum using a + b.
Ruby
Hint

Define add method with two parameters and return their sum.

3
Run the test and store the result
Call the test_addition method to run the test. Then call add(2, 3) and store the result in a variable named result.
Ruby
Hint

Call test_addition to run the test, then assign add(2, 3) to result.

4
Print the result
Print the value of the variable result using puts result.
Ruby
Hint

Use puts result to display the sum.

Practice

(1/5)
1. In Ruby's test-driven development (TDD) workflow, what is the first step you should do?
easy
A. Run all tests to check for errors
B. Write a failing test that defines the desired behavior
C. Refactor the existing code
D. Write the full implementation code

Solution

  1. Step 1: Understand the TDD cycle

    The TDD cycle starts by writing a test that fails because the feature is not implemented yet.
  2. Step 2: Identify the first action in TDD

    Writing a failing test first guides the development and ensures the code meets requirements.
  3. Final Answer:

    Write a failing test that defines the desired behavior -> Option B
  4. Quick Check:

    First step in TDD = Write failing test [OK]
Hint: Remember: Test first, code second in TDD [OK]
Common Mistakes:
  • Starting by writing implementation code before tests
  • Refactoring before any test is written
  • Running tests before any code or test exists
2. Which Ruby command runs all tests in a typical TDD workflow using Minitest?
easy
A. rails server
B. rspec test_file.rb
C. ruby test_file.rb
D. bundle install

Solution

  1. Step 1: Identify the test framework command

    Minitest tests are run by executing the Ruby test file directly with ruby test_file.rb.
  2. Step 2: Eliminate unrelated commands

    rspec is for RSpec tests, rails server starts the server, and bundle install installs gems.
  3. Final Answer:

    ruby test_file.rb -> Option C
  4. Quick Check:

    Run Minitest with ruby test_file.rb [OK]
Hint: Run tests by executing test files with ruby [OK]
Common Mistakes:
  • Using rspec command for Minitest tests
  • Confusing server start with test run
  • Running bundle install instead of tests
3. Given this Ruby test and code, what will be the test output?
require 'minitest/autorun'

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

class TestCalculator < Minitest::Test
  def test_add
    calc = Calculator.new
    assert_equal 5, calc.add(2, 3)
  end
end
medium
A. 1 test, 0 failures
B. 1 test, 1 failure
C. SyntaxError
D. No tests run

Solution

  1. Step 1: Analyze the test and method

    The add method returns the sum of two numbers. The test expects 5 from adding 2 and 3.
  2. Step 2: Check if test passes

    Since 2 + 3 equals 5, the assertion passes and the test succeeds.
  3. Final Answer:

    1 test, 0 failures -> Option A
  4. Quick Check:

    Correct sum = test passes [OK]
Hint: If method matches test expectation, test passes [OK]
Common Mistakes:
  • Thinking test fails when it actually passes
  • Confusing syntax error with test failure
  • Ignoring the assert_equal expected value
4. What is wrong with this TDD workflow snippet in Ruby?
class TestCalculator < Minitest::Test
  def test_multiply
    calc = Calculator.new
    assert_equal 6, calc.multiply(2, 3)
  end
end

class Calculator
  def multiply(a, b)
    a - b
  end
end
medium
A. The test method name is incorrect
B. assert_equal arguments are reversed
C. Calculator class is missing
D. The multiply method subtracts instead of multiplies

Solution

  1. Step 1: Compare method implementation with test expectation

    The test expects multiply(2, 3) to return 6, but the method subtracts a - b.
  2. Step 2: Identify the error cause

    Subtracting 2 - 3 gives -1, which will fail the test expecting 6.
  3. Final Answer:

    The multiply method subtracts instead of multiplies -> Option D
  4. Quick Check:

    Method logic must match test expectation [OK]
Hint: Check method logic matches test assertions [OK]
Common Mistakes:
  • Confusing subtraction with multiplication
  • Ignoring method implementation details
  • Assuming test method name affects test result
5. You want to safely improve your Ruby code after passing tests. Which TDD step lets you do this without breaking functionality?
hard
A. Refactor the code while running tests frequently
B. Write new tests before changing code
C. Run tests only after all changes are done
D. Delete old tests to simplify code

Solution

  1. Step 1: Understand the role of refactoring in TDD

    Refactoring means improving code structure without changing behavior, done safely with tests as a safety net.
  2. Step 2: Identify the correct practice

    Running tests frequently during refactoring ensures no functionality breaks.
  3. Final Answer:

    Refactor the code while running tests frequently -> Option A
  4. Quick Check:

    Refactor + frequent tests = safe improvements [OK]
Hint: Refactor with tests running often to catch errors [OK]
Common Mistakes:
  • Running tests only after all changes
  • Deleting tests which protect code quality
  • Writing tests after refactoring instead of before
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard