Test-driven development workflow in Ruby - Step-by-Step Execution

Concept Flow - Test-driven development workflow

Write a failing test

↓

Run the test suite

↓

Test fails as expected

↓

Write code to pass test

↓

Run the test suite again

↓

Test passes

↓

Refactor code if needed

↓

Repeat cycle for next feature

This flow shows the cycle of writing a test first, running it to see it fail, then writing code to pass the test, running tests again to confirm success, and finally refactoring.

Execution Sample

Ruby

require 'minitest/autorun'

def add(a, b)
  a + b
end

class TestAdd < Minitest::Test
  def test_addition
    assert_equal 5, add(2, 3)
  end
end

This Ruby code defines a simple add method and a test that checks if add(2, 3) returns 5.

Execution Table

Step	Action	Evaluation	Result
1	Write test 'test_addition' expecting add(2,3) == 5	No code yet	Test will fail if run
2	Run tests	TestAdd#test_addition runs	Fails (method add not defined or incorrect)
3	Write method add(a,b) returning a + b	Method defined	Ready to pass test
4	Run tests again	TestAdd#test_addition runs	Passes (5 == 5)
5	Refactor code if needed	No change in behavior	Tests still pass
6	Cycle repeats for next feature	New test written	Process repeats

💡 Tests pass and code is clean, cycle repeats for new features

Variable Tracker

Variable	Start	After Step 3	After Step 4	Final
add method	undefined	defined as a + b	same	same

Key Moments - 3 Insights

Why do we write the test before the code?

Writing the test first ensures we know exactly what the code should do. As shown in execution_table step 1 and 2, the test fails initially, guiding us to write just enough code to pass it.

What does it mean when the test fails at first?

The failure confirms the test is valid and the feature is not yet implemented. This is shown in execution_table step 2 where the test fails before the method is defined.

Why do we run tests again after writing code?

Running tests again (step 4) confirms the new code meets the test requirements and works correctly before moving on.

Visual Quiz - 3 Questions

Look at the execution_table at step 2, what is the test result?

A Test passes successfully

B Test fails because code is missing or incorrect

C Test is skipped

D Test crashes the program

💡 Hint

See execution_table row with Step 2 showing test failure due to missing or incorrect code

At which step does the test pass?

A Step 1

B Step 3

C Step 4

D Step 6

💡 Hint

Check execution_table row Step 4 where tests run and pass after code is written

If we skip writing the test first, how would the execution_table change?

A Step 1 would be missing and tests might pass or fail unpredictably

B Step 2 would show test failure as usual

C Step 3 would be writing the test instead of code

D Step 5 would be refactoring before writing code

💡 Hint

Look at the flow: test first guides the process; skipping it removes step 1

Concept Snapshot

Test-driven development (TDD) workflow:
1. Write a failing test for new feature.
2. Run tests to confirm failure.
3. Write minimal code to pass test.
4. Run tests to confirm success.
5. Refactor code while tests pass.
6. Repeat cycle for next feature.

Full Transcript

Test-driven development is a cycle where you first write a test that fails because the feature is not implemented. Then you write just enough code to pass that test. After that, you run the tests again to confirm the code works. Finally, you can clean up the code without changing its behavior. This cycle repeats for every new feature or fix. The example Ruby code shows a test for an add method that initially fails, then passes after the method is defined. This approach helps ensure your code does exactly what you want and makes it easier to catch mistakes early.

Practice

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