On the Joy of Writing Tests

Writing tests is often seen as a chore by many developers. They commonly cite reasons like:

“It takes too much time”
“The requirements might change”
“I know my code works”
“Tests are hard to maintain”

However, these perspectives miss the fundamental value that testing brings to software development. Let’s explore why testing should be embraced rather than avoided, especially in Go, which provides excellent testing tools out of the box.

The best thing about writing good tests is how much easier it makes your work. Let me share a real example: I was building the backend of a Neovim plugin in Go, and I needed to test many API endpoints. Without tests, I would have to keep switching between my code editor (Neovim, btw) and Postman (an API testing tool) to check if everything worked. But once I started writing tests, I could do everything right in my code editor. I didn’t need to open Postman even once. This made my work much faster and smoother. Instead of jumping between different tools, I could focus on writing code and making sure it worked correctly through tests.

I’m going to be honest. I’m relatively new to writing tests. But even in this short time, the impact has been so profound that I felt compelled to share my experience. The productivity boost was so significant that I went from being skeptical to becoming its advocate.

The Direction Tests Provide

Think of tests as a compass for your code. Before writing a single line of implementation, tests force you to think about:

What inputs your code should handle
What outputs you expect
Edge cases and error scenarios
The public API of your package

Here’s a simple example. Let’s say we want to write a function that validates email addresses:

// Without tests, we might jump straight to implementation:
func ValidateEmail(email string) bool {
    // Add some regex here...
    return true
}

But with tests, we first think about scenarios:

func TestValidateEmail(t *testing.T) {
    tests := []struct {
        name  string
        email string
        want  bool
    }{
        {"valid email", "user@example.com", true},
        {"missing @", "userexample.com", false},
        {"multiple @", "user@@example.com", false},
        {"invalid characters", "user!@example.com", false},
        {"empty string", "", false},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            if got := ValidateEmail(tt.email); got != tt.want {
                t.Errorf("ValidateEmail() = %v, want %v", got, tt.want)
            }
        })
    }
}

Now we have a clear specification of what our function should do!

Test-Driven vs. Code-Driven Tests

Test-Driven Development (TDD)

In TDD, you write tests before implementation. The workflow is:

Write a failing test
Write the minimal code to make it pass
Refactor
Repeat

// Step 1: Write the test first
func TestSum(t *testing.T) {
    got := Sum(2, 3)
    want := 5
    if got != want {
        t.Errorf("Sum(2, 3) = %d; want %d", got, want)
    }
}

// Step 2: Write the minimal implementation
func Sum(a, b int) int {
    return a + b
}

Code-Driven Tests

Here, you write code first, then add tests afterward:

// Write implementation first
func ProcessOrder(order Order) (string, error) {
    if order.ID == "" {
        return "", errors.New("order ID required")
    }
    // Process the order...
    return order.ID, nil
}

// Then add tests
func TestProcessOrder(t *testing.T) {
    // Test cases follow the implementation
    // Often missing edge cases you didn't think about
}

The main difference? TDD helps you design better interfaces and catch edge cases early, while code-driven tests often end up testing the implementation rather than the behavior.

Go’s Testing Toolkit

Go provides several powerful testing tools:

Table-Driven Tests

The most common pattern in Go tests:

func TestCalculator(t *testing.T) {
    tests := []struct {
        name     string
        a, b     int
        op       string
        want     int
        wantErr  bool
    }{
        {"simple addition", 2, 2, "+", 4, false},
        {"negative numbers", -1, -1, "+", -2, false},
        {"division by zero", 1, 0, "/", 0, true},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got, err := Calculate(tt.a, tt.b, tt.op)
            if (err != nil) != tt.wantErr {
                t.Errorf("Calculate() error = %v, wantErr %v", err, tt.wantErr)
                return
            }
            if !tt.wantErr && got != tt.want {
                t.Errorf("Calculate() = %v, want %v", got, tt.want)
            }
        })
    }
}

Subtests

Go 1.7+ allows grouping related tests:

func TestUserService(t *testing.T) {
    t.Run("group: creation", func(t *testing.T) {
        t.Run("valid user", func(t *testing.T) {
            // Test valid user creation
        })
        t.Run("invalid email", func(t *testing.T) {
            // Test invalid email handling
        })
    })
}

Testing Helpers

Write reusable testing utilities:

func setupTestDB(t *testing.T) *sql.DB {
    t.Helper() // Marks this as a helper function
    db, err := sql.Open("postgres", "postgres://test:test@localhost:5432/testdb")
    if err != nil {
        t.Fatal(err)
    }
    return db
}

Benchmarks

Measure performance:

func BenchmarkFibonacci(b *testing.B) {
    for i := 0; i < b.N; i++ {
        Fibonacci(20)
    }
}

Building a Testing Culture

Good tests lead to:

Confident refactoring
Better documentation
Fewer bugs
Clearer interfaces
Happy developers (yes, really!)

Some tips for better testing:

Make testing easy (good tooling, CI integration)
Test behavior, not implementation
Keep tests readable
Don’t test everything - focus on business logic
Use coverage tools as guidelines, not goals

Go Testing Tools and Commands

Test Coverage

Go provides built-in tools for analyzing test coverage. Here’s how to use them:

# Run tests with coverage profile
go test -coverprofile=coverage.out

# View coverage in browser
go tool cover -html=coverage.out

# Get coverage percentage
go test -cover

# Coverage for specific packages
go test ./... -coverprofile=coverage.out

The coverage profile shows which lines of code are tested:

Green: Covered by tests
Red: Not covered
Grey: Non-executable lines

Example of using coverage in CI:

// coverage_test.go
func TestWithCoverage(t *testing.T) {
    tests := []struct {
        name    string
        input   string
        want    string
        wantErr bool
    }{
        {"happy path", "hello", "HELLO", false},
        // Missing test case for empty string!
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got, err := ProcessString(tt.input)
            if (err != nil) != tt.wantErr {
                t.Errorf("ProcessString() error = %v, wantErr %v", err, tt.wantErr)
                return
            }
            if got != tt.want {
                t.Errorf("ProcessString() = %v, want %v", got, tt.want)
            }
        })
    }
}

Race Detection

Go’s race detector is invaluable for finding concurrency issues:

# Run tests with race detection
go test -race

# Run specific test with race detection
go test -race -run=TestConcurrent

Example of a race condition test:

func TestConcurrentAccess(t *testing.T) {
    counter := &Counter{}
    var wg sync.WaitGroup

    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            counter.Increment()
        }()
    }
    wg.Wait()
}

Test Filtering

Go offers various ways to run specific tests:

# Run tests matching a pattern
go test -run=TestUser

# Run a specific subtest
go test -run=TestUser/valid_email

# Run tests in verbose mode
go test -v

# Run tests in a specific package
go test ./internal/user

# Run tests for all packages
go test ./...

Test Caching

Go caches test results to speed up subsequent runs:

# Clear test cache
go clean -testcache

# Disable test caching
go test -count=1

Benchmark Tools

Advanced benchmark usage:

# Run benchmarks
go test -bench=.

# Run benchmarks with memory allocation stats
go test -bench=. -benchmem

# Compare benchmarks (requires benchstat tool)
# First run:
go test -bench=. > old.txt
# After changes:
go test -bench=. > new.txt
benchstat old.txt new.txt

Example benchmark with sub-benchmarks:

func BenchmarkComplexOperation(b *testing.B) {
    sizes := []int{100, 1000, 10000}
    for _, size := range sizes {
        b.Run(fmt.Sprintf("size-%d", size), func(b *testing.B) {
            data := makeTestData(size)
            b.ResetTimer()
            for i := 0; i < b.N; i++ {
                ProcessData(data)
            }
        })
    }
}

Integration with IDE’s

Most Go-aware IDEs can:

Show coverage highlights inline
Run specific tests with a click
Debug tests
Show benchmark results graphically

Popular IDE integrations:

VS Code with Go extension
GoLand
Vim/Neovim with gopls

Custom Test Binary

You can create a test binary for debugging or profiling:

# Create test binary
go test -c

# Run with specific flags
./package.test -test.v -test.run=TestSpecific

Profiling Tests

Go’s testing framework integrates with pprof:

# CPU profiling
go test -cpuprofile=cpu.prof

# Memory profiling
go test -memprofile=mem.prof

# Block profiling (goroutine blocking)
go test -blockprofile=block.prof

# Analyze with pprof
go tool pprof cpu.prof

[Previous “Building a Testing Culture” and “Conclusion” sections remain the same]

Pro Tips for Test Organization

Use Test Suites: Group related tests together

type UserTestSuite struct {
    db *sql.DB
    // ... other test dependencies
}

func (s *UserTestSuite) SetupTest(t *testing.T) {
    // Setup test environment
}

func (s *UserTestSuite) TearDownTest(t *testing.T) {
    // Cleanup
}

Test Fixtures: Keep test data organized

// testdata/users.json
{
    "valid_user": {
        "email": "test@example.com",
        "name": "Test User"
    }
}

Golden Files: For complex output comparison

func TestComplexOutput(t *testing.T) {
    got := GenerateReport()
    golden := "testdata/report.golden"

    if *update {
        t.Log("updating golden file")
        if err := os.WriteFile(golden, []byte(got), 0644); err != nil {
            t.Fatalf("failed to update golden file: %s", err)
        }
    }

    want, err := os.ReadFile(golden)
    if err != nil {
        t.Fatalf("failed reading golden file: %s", err)
    }

    if got != string(want) {
        t.Errorf("output differs from golden file")
    }
}

Remember: These tools are meant to help you write better tests, not to achieve arbitrary metrics. Use them wisely to improve your testing strategy and code quality.

Conclusion

Testing isn’t just about catching bugs - it’s about designing better software. When you write tests first, you’re forced to think about your code from the user’s perspective. This leads to better APIs, clearer error handling, and more maintainable code.

Next time you start a new feature, try writing the tests first. You might find that the joy of having well-tested code outweighs the initial investment in writing those tests.

The Direction Tests Provide#

Test-Driven vs. Code-Driven Tests#

Test-Driven Development (TDD)#

Code-Driven Tests#

Go’s Testing Toolkit#

Table-Driven Tests#

Subtests#

Testing Helpers#

Benchmarks#

Building a Testing Culture#

Go Testing Tools and Commands#

Test Coverage#

Race Detection#

Test Filtering#

Test Caching#

Benchmark Tools#

Integration with IDE’s#

Custom Test Binary#

Profiling Tests#

Pro Tips for Test Organization#

Conclusion#