Running tests in Go - Time & Space Complexity

Time Complexity: Running tests

O(n)

Understanding Time Complexity

When running tests in Go, it's important to know how the time needed grows as tests increase.

We want to see how the total test time changes when we add more tests.

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

func TestAll(t *testing.T) {
    for i := 0; i < len(testCases); i++ {
        i := i // capture loop variable
        t.Run(testCases[i].name, func(t *testing.T) {
            result := SomeFunction(testCases[i].input)
            if result != testCases[i].expected {
                t.Errorf("got %v, want %v", result, testCases[i].expected)
            }
        })
    }
}

This code runs a series of tests, one for each case in the testCases list.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Looping through each test case and running a test.
• How many times: Once for each test case in the list.

How Execution Grows With Input

Each test case adds one more test to run, so the total time grows as the number of tests grows.

Input Size (n)	Approx. Operations
10	Runs 10 tests
100	Runs 100 tests
1000	Runs 1000 tests

Pattern observation: The total work grows directly with the number of tests.

Final Time Complexity

Time Complexity: O(n)

This means the total test time grows in a straight line as you add more tests.

Common Mistake

[X] Wrong: "Running more tests doesn't affect total time much because tests run fast."

[OK] Correct: Even if each test is quick, adding many tests adds up, so total time grows with the number of tests.

Interview Connect

Understanding how test time grows helps you write efficient tests and manage testing time well in real projects.

Self-Check

"What if each test case itself runs a loop over data? How would the time complexity change?"

Practice

1. What is the correct way to name a test function in Go so that go test can run it?

easy

A. Start the function name with Test

B. Start the function name with test (lowercase t)

C. Name the function RunTest

D. Name the function CheckTest

Solution

1. Step 1: Understand Go test naming rules

   Go requires test functions to start with an uppercase Test to be recognized by go test.

2. Step 2: Check the options

   Only Start the function name with Test starts with Test exactly, others do not follow the naming convention.

3. Final Answer:

   Start the function name with Test -> Option A

4. Quick Check:

   Test functions start with 'Test' [OK]

Hint: Test functions must start with uppercase 'Test' [OK]

Common Mistakes:

• Using lowercase 'test' at start
• Naming test functions without 'Test' prefix
• Using unrelated prefixes like 'Run' or 'Check'

2. Which of the following is the correct syntax to run tests in a Go module from the command line?

easy

A. go execute test

B. go run test

C. go build test

D. go test

Solution

1. Step 1: Recall Go test command

   The command to run tests in Go is go test.

2. Step 2: Compare options

   Only go test matches the correct command. Others are invalid commands.

3. Final Answer:

   go test -> Option D

4. Quick Check:

   Run tests with 'go test' [OK]

Hint: Use 'go test' to run tests, not 'go run' [OK]

Common Mistakes:

• Using 'go run test' instead of 'go test'
• Trying 'go build test' which builds but doesn't test
• Using non-existent commands like 'go execute test'

3. What will be the output when running go test on this test file?

package main

import "testing"

func TestSum(t *testing.T) {
  if 2+2 != 4 {
    t.Error("Sum failed")
  }
}

medium

A. Syntax error: missing main function

B. FAIL
--- FAIL: TestSum

C. PASS
ok main 0.001s

D. No tests to run

Solution

1. Step 1: Analyze the test logic

   The test checks if 2+2 equals 4, which is true, so no error is called.

2. Step 2: Understand test output

   Since the test passes, go test outputs PASS with timing info.

3. Final Answer:

   PASS ok main 0.001s -> Option C

4. Quick Check:

   Test passes, so output shows PASS [OK]

Hint: If test condition is true, output shows PASS [OK]

Common Mistakes:

• Assuming syntax error due to missing main
• Expecting FAIL when condition is true
• Thinking tests won't run without main function

4. Identify the error in this test function that prevents go test from running it:

package main

import "testing"

func testAdd(t *testing.T) {
  if 1+1 != 2 {
    t.Error("Add failed")
  }
}

medium

A. Missing import of 'fmt' package

B. Function name must start with uppercase 'Test'

C. Test function must return a value

D. Test functions cannot have parameters

Solution

1. Step 1: Check test function naming

   The function is named testAdd with lowercase 't', so go test ignores it.

2. Step 2: Verify other requirements

   Test functions must start with uppercase 'Test' and accept *testing.T parameter, which is correct except the name.

3. Final Answer:

   Function name must start with uppercase 'Test' -> Option B

4. Quick Check:

   Test functions need 'Test' prefix [OK]

Hint: Test functions must start with uppercase 'Test' [OK]

Common Mistakes:

• Thinking test functions need to return a value
• Assuming missing 'fmt' import causes test failure
• Believing test functions cannot have parameters

5. You want to run only tests in the file math_test.go inside your module. Which command should you use?

hard

A. go test math_test.go

B. go test -file math_test.go

C. go test -v

D. go test -run math_test.go

Solution

1. Step 1: Understand how to run tests in a specific file

   Go allows specifying test files directly as arguments to go test.

2. Step 2: Check options for correct usage

   Only go test math_test.go runs tests in the specified file. B uses invalid -file flag, C's go test -v runs all tests verbosely, D's -run matches test names.

3. Final Answer:

   go test math_test.go -> Option A

4. Quick Check:

   Specify test file directly to run its tests [OK]

Hint: Run tests in a file by naming it after 'go test' [OK]

Common Mistakes:

• Using invalid flags like -run or -file with filenames
• Confusing verbose flag -v with file selection
• Not specifying the file and running all tests