ProgramGuru

Table-Driven Tests

Start with Table-Driven Tests

In this lesson, explore table-driven tests through one small Go program, and connect its output to the language rules behind it.

What you’ll learn

  • Explain the main purpose of table-driven tests.
  • Read and run the complete Go example in this lesson.
  • Apply the concept and recognize common mistakes.

Understand the idea

Table-driven tests place inputs and expected outcomes in a slice of cases. One loop executes the same assertion logic against each case, reducing repetitive test code.

Include boundary cases and clear case names. Use t.Run with each case to make failures easy to identify.

Visualize how it works

Follow this diagram before executing the example. Check where a value or decision changes what runs next.

Visual explanation for table testsOne table keeps test expectations visible.Case tableStep 1Run each inputStep 2Compare outputStep 3Name failuresStep 4One table keeps test expectations visible.
One table keeps test expectations visible.

Tools, syntax and practical notes

square_test.go

package main
import "testing"
func TestSquare(t *testing.T) {
    cases := []struct{name string; n, want int}{
        {"zero",0,0},{"positive",2,4},{"negative",-3,9},
    }
    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            if got := square(tc.n); got != tc.want { t.Errorf("got %d; want %d", got, tc.want) }
        })
    }
}

Run a complete Go example

This example is a complete program. Save it as main.go or paste it into the Go Playground.

Go code

package main

import "fmt"

func square(n int) int { return n * n }
func main() {
	cases := []struct{ n, want int }{{0, 0}, {2, 4}, {-3, 9}}
	passed := 0
	for _, tc := range cases {
		if square(tc.n) == tc.want {
			passed++
		}
	}
	fmt.Println("Cases passed:", passed)
}

Output

Cases passed: 3

Trace what the program does

The three cases cover zero, positive and negative numbers. All expected outputs match, so the example prints Cases passed: 3.

Avoid common mistakes

  • Do not silently skip a test case when adding entries.
  • For parallel subtests, check loop-variable capture rules on the target Go release.

Try it yourself

Add a case for -5 and an expected square of 25.

Tip: Edit the example above, predict the output, and run the modified code to test your reasoning.

Check your understanding

Why use a slice of test cases?
Choose one answer. You can try again.

Answer and explanation

To exercise multiple inputs with one assertion pattern

Correct. The three cases cover zero, positive and negative numbers.

What you should remember

You have practiced Table-Driven Tests in a small, self-contained program. The important habit is to predict what runs, inspect the actual output and distinguish the language rule from the particular example.

Before continuing, make sure you can explain the program to someone who has not seen it, including the line that changes its result.

Reaching the recap and completing the quizzes are separate milestones.

    Next lesson: Subtests →