Test-driven development workflow in Ruby - Time & Space Complexity

Time Complexity: Test-driven development workflow

O(n)

Understanding Time Complexity

We want to understand how the time spent changes when following the test-driven development workflow in Ruby.

How does the number of tests and code changes affect the time it takes to run tests repeatedly?

Scenario Under Consideration

Analyze the time complexity of this simple test-driven development cycle.

    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
    

This code defines a simple Calculator class and a test that checks the add method.

Identify Repeating Operations

In test-driven development, the main repeating operation is running the test suite.

• Primary operation: Running all tests after each code change.
• How many times: Once per code change, repeated many times during development.

How Execution Grows With Input

As the number of tests grows, the time to run all tests grows too.

Input Size (number of tests)	Approx. Operations (test runs)
10	10 test runs per cycle
100	100 test runs per cycle
1000	1000 test runs per cycle

Pattern observation: The time to run tests grows roughly in direct proportion to the number of tests.

Final Time Complexity

Time Complexity: O(n)

This means the time to run all tests grows linearly with the number of tests.

Common Mistake

[X] Wrong: "Running one test is always fast, so adding more tests won't slow things down much."

[OK] Correct: Each test adds time, so many tests add up and make the total test run longer.

Interview Connect

Understanding how test suite size affects development speed helps you write better tests and manage time well in real projects.

Self-Check

"What if we only run tests related to changed code instead of all tests? How would the time complexity change?"