Test-driven development workflow in Ruby - Deep Dive

Overview - Test-driven development workflow

What is it?

Test-driven development (TDD) is a way to write software by first creating tests that describe what the code should do, then writing the code to pass those tests. It is a cycle of writing a failing test, making it pass, and then improving the code. This helps ensure the software works correctly and is easier to maintain.

Why it matters

Without TDD, developers might write code that has hidden bugs or unclear behavior, leading to more time fixing problems later. TDD helps catch mistakes early, improves design, and builds confidence that the code works as expected. It makes software development more predictable and less stressful.

Where it fits

Before learning TDD, you should understand basic programming and how to write simple tests. After mastering TDD, you can explore advanced testing techniques, continuous integration, and behavior-driven development.

Mental Model

Core Idea

Write a small test first, then write just enough code to pass it, and finally improve the code before repeating.

Think of it like...

It's like writing a recipe step by step: first decide what dish you want (test), then add ingredients one by one (code), tasting after each step to make sure it’s right (test passes), and finally make the dish look and taste better (refactor).

┌───────────────┐
│ Write a Test  │
└──────┬────────┘
       │ Fails
       ▼
┌───────────────┐
│ Write Code to │
│ Pass the Test │
└──────┬────────┘
       │ Passes
       ▼
┌───────────────┐
│ Refactor Code │
└──────┬────────┘
       │
       ▼
   Repeat Cycle

Build-Up - 7 Steps

1

Foundation

Understanding Tests and Code

Concept: Learn what tests and code are and how they relate.

In programming, code is the instructions you write to make a computer do something. Tests are special programs that check if your code works correctly. Think of tests as questions you ask your code to make sure it answers correctly.

Result

You know that tests check code behavior and that code is what makes programs work.

Understanding that tests are like safety checks helps you see why writing tests first can guide your coding.

2

Foundation

The Red-Green-Refactor Cycle

Concept: Introduce the three-step cycle of TDD.

TDD follows a simple loop: first, write a test that fails (red), then write code to make it pass (green), and finally clean up the code without changing its behavior (refactor). This cycle repeats for every small feature.

Result

You can follow the TDD cycle to build software step by step.

Knowing this cycle gives you a clear, manageable way to develop software with confidence.

3

Intermediate

Writing Your First Failing Test

🤔Before reading on: do you think writing a test before code helps or slows you down? Commit to your answer.

Concept: Learn how to write a test that describes desired behavior before any code exists.

In Ruby, you can use a testing tool like Minitest or RSpec. For example, write a test that expects a method to return a value. Since the method doesn't exist yet, the test will fail, showing what you want to build.

Result

You create a clear goal for your code by writing a failing test first.

Writing tests first forces you to think about what your code should do, preventing guesswork.

4

Intermediate

Making the Test Pass with Minimal Code

🤔Before reading on: do you think you should write perfect code immediately or just enough to pass the test? Commit to your answer.

Concept: Write the simplest code that makes the failing test pass.

After the test fails, write just enough Ruby code to pass it. For example, if the test expects a method to return 5, write a method that returns 5. Avoid adding extra features or complexity now.

Result

The test passes, confirming your code meets the requirement.

Focusing on minimal code reduces errors and keeps development focused on requirements.

5

Intermediate

Refactoring Code Safely

🤔Before reading on: do you think refactoring can break your code if you have tests? Commit to your answer.

Concept: Improve code structure and readability without changing behavior, using tests as a safety net.

Once tests pass, clean up your Ruby code by removing duplication, renaming variables, or simplifying logic. Run tests after each change to ensure nothing breaks.

Result

Your code becomes cleaner and easier to maintain without losing functionality.

Tests give you confidence to improve code quality without fear of introducing bugs.

6

Advanced

Handling Complex Features with TDD

🤔Before reading on: do you think TDD works well for complex features or only simple ones? Commit to your answer.

Concept: Apply TDD to build complex features by breaking them into small, testable parts.

For complex Ruby programs, divide features into smaller units and write tests for each. Use mocks or stubs to isolate parts. This keeps tests fast and focused, making development manageable.

Result

You can build large, complex software reliably using TDD.

Breaking complexity into small tests prevents overwhelm and keeps development steady.

7

Expert

Avoiding Common TDD Pitfalls

🤔Before reading on: do you think writing many tests always improves code quality? Commit to your answer.

Concept: Recognize when tests become a burden and how to write meaningful tests that add value.

Too many or poorly designed tests can slow development and cause false confidence. Focus on testing behavior, not implementation details. Use integration tests wisely and keep unit tests fast and clear.

Result

Your test suite remains helpful and maintainable over time.

Knowing when and what to test is as important as testing itself to keep TDD effective.

Under the Hood

TDD works by using automated tests as a contract for code behavior. When you run tests, the Ruby interpreter executes test code that calls your program code and checks results. If a test fails, it signals that the code does not meet the expected behavior. This feedback loop guides development and prevents regressions.

Why designed this way?

TDD was designed to reduce bugs and improve design by forcing developers to think about requirements before coding. It contrasts with writing code first and testing later, which often leads to unclear requirements and fragile code. The cycle encourages small, incremental progress and continuous verification.

┌───────────────┐
│ Write Test    │
│ (Fails)      │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Write Code    │
│ (Pass Test)  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Refactor Code │
│ (Keep Tests) │
└──────┬────────┘
       │
       ▼
   Repeat Cycle

Myth Busters - 4 Common Misconceptions

Quick: Does writing tests first slow down development? Commit to yes or no.

Common Belief: Writing tests before code slows down the development process.

Reality: While it may feel slower at first, TDD saves time by catching bugs early and reducing debugging later.

Why it matters: Believing this can discourage developers from using TDD, leading to more bugs and longer development cycles.

Quick: Do tests written in TDD guarantee bug-free code? Commit to yes or no.

Common Belief: If all tests pass, the code is completely bug-free.

Reality: Passing tests mean the code meets tested requirements, but untested scenarios or wrong tests can still hide bugs.

Why it matters: Overconfidence in tests can cause missed bugs and false security.

Quick: Is TDD only useful for small projects? Commit to yes or no.

Common Belief: TDD is only practical for small or simple projects.

Reality: TDD scales to large projects by breaking features into small tests and using test doubles to manage complexity.

Why it matters: Ignoring TDD for big projects misses out on its benefits for maintainability and reliability.

Quick: Does refactoring always require rewriting tests? Commit to yes or no.

Common Belief: Every time you refactor code, you must rewrite or change tests.

Reality: Good tests focus on behavior, so refactoring internal code usually does not require changing tests.

Why it matters: Misunderstanding this can lead to unnecessary test rewrites and wasted effort.

Expert Zone

1

Tests should focus on behavior, not implementation details, to avoid brittle tests that break with harmless code changes.

2

Using test doubles like mocks and stubs strategically helps isolate units and speeds up tests without losing reliability.

3

Refactoring tests themselves is important to keep them readable and maintainable as the code evolves.

When NOT to use

TDD is less effective for exploratory coding where requirements are unclear or rapidly changing. In such cases, prototyping or spike solutions without tests first may be better. Also, for simple throwaway scripts, writing tests may be unnecessary overhead.

Production Patterns

In real projects, TDD is combined with continuous integration to run tests automatically on every code change. Teams use code coverage tools to ensure tests cover important parts. Tests are organized into unit, integration, and acceptance levels to balance speed and confidence.

Connections

Continuous Integration

Builds-on

Understanding TDD helps grasp how continuous integration automates running tests to catch problems early in the development pipeline.

Behavior-driven Development (BDD)

Related approach

Knowing TDD clarifies how BDD extends it by focusing tests on user behavior and collaboration between developers and non-technical stakeholders.

Scientific Method

Same pattern

TDD mirrors the scientific method: form a hypothesis (write test), experiment (write code), observe results (run test), and refine (refactor), showing how software development can be a disciplined, iterative process.

Common Pitfalls

#1 Writing tests that check internal code details instead of behavior.

Wrong approach:

expect(user.name).to eq('Alice') # checks exact attribute, fragile if implementation changes

Correct approach:

expect(user.display_name).to eq('Alice') # checks behavior, stable if internals change

Root cause:

Confusing how the code works internally with what it should do externally.

#2 Skipping refactoring after tests pass, leading to messy code.

Wrong approach:

def add(a,b); return a+b; end # no cleanup or simplification after passing tests

Correct approach:

def add(a, b)
a + b
end # clean, simple code after refactoring

Root cause:

Not valuing code quality or misunderstanding that refactoring is part of TDD.

#3 Writing large tests that cover too much at once, making failures hard to diagnose.

Wrong approach:

test 'complex feature' do
# many steps and assertions in one test
end

Correct approach:

test 'small unit behavior' do
# focused, single assertion test
end

Root cause:

Trying to test too much at once instead of breaking features into small parts.

Key Takeaways

Test-driven development is a cycle of writing a failing test, making it pass, and then improving the code.

Writing tests first helps clarify what the code should do and prevents bugs early.

Refactoring with tests ensures code stays clean without breaking functionality.

TDD scales to complex projects by breaking features into small, testable units.

Good tests focus on behavior, not internal details, to remain stable and useful.

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