How to Write Testable Code in Golang: A Practical Guide

gocloudwithus
Mar 11, 2025
4 min read

Introduction

If you’ve ever worked on a large Golang project, you’ve probably faced the frustration of debugging or modifying tightly coupled, untestable code. Maybe you found yourself running the entire application just to check if a tiny change worked. That’s a sign of bad design.

But what if I told you that writing testable code isn’t just about making testing easier — it also leads to better software architecture, cleaner code, and fewer headaches in production?

In this post, I’ll walk you through practical techniques to write modular, testable Go code using dependency injection, interfaces, and table-driven tests. By the end, you’ll be able to write Go code that’s not just easy to test but also easy to maintain and extend.

Why Should You Care About Testability?

Many developers think testing is something you “do later” when writing code. That’s a mistake.

Testability isn’t just about writing tests — it’s about designing code that is naturally easy to test. If your code is testable, it’s:

Easier to debug → No more spending hours tracing through spaghetti code.

More maintainable → Future changes won’t break everything.

Scalable → You can add features with confidence.

Supports CI/CD → Automated tests ensure you don’t deploy broken code.

How to Write Testable Code in Go

Let’s build a small User Service that fetches user details from a database. I’ll show you how to:

Use interfaces to abstract dependencies.
Use dependency injection to avoid tight coupling.
Write mock implementations for testing.
Use table-driven tests for better test coverage.

Step 1: Define an Interface for the Repository

In real-world applications, we interact with databases, APIs, and other services. But if we hardcode database queries inside our service, testing becomes a nightmare.

Instead, we use interfaces to abstract database logic:

📂 repository/user_repository.go

package repository
import "errors"

type User struct {
 ID   int
 Name string
}

// UserRepository defines an interface for database access
type UserRepository interface {
 GetUserByID(id int) (*User, error)
}

👉 Why? Interfaces allow us to easily swap the real database implementation with a mock one for testing.

Step 2: Implement the Actual Database Repository

This is how we’d normally fetch user data from a database (simulated for now).

📂 repository/user_db.go

package repository

import "errors"

type RealDBRepository struct{}

func (r *RealDBRepository) GetUserByID(id int) (*User, error) {
 if id == 1 {
  return &User{ID: 1, Name: "John Doe"}, nil
 }
 return nil, errors.New("user not found")
}

💡 But what if we don’t want to hit a real database every time we run tests?We solve that in Step 4 by using mock implementations.

Step 3: Implement the Service Layer (Business Logic)

The service layer should contain business logic, not database queries.

📂 service/user_service.go

package service

import (
 "errors"
 "example.com/repository"
)

type UserService struct {
 repo repository.UserRepository
}

// NewUserService creates a new service with dependency injection
func NewUserService(repo repository.UserRepository) *UserService {
 return &UserService{repo: repo}
}

func (s *UserService) GetUserByID(id int) (string, error) {
 user, err := s.repo.GetUserByID(id)
 if err != nil {
  return "", errors.New("user not found")
 }
 return "User: " + user.Name, nil
}

👉 Why? This keeps database logic separate from business logic.👉 Bonus: If we switch from PostgreSQL to MongoDB later, we only update the repository, not the service!

Step 4: Create a Mock Repository for Testing

Instead of hitting a real database, let’s create a mock implementation for testing.

📂 repository/user_mock.go

package repository

// MockRepository simulates a fake database
type MockRepository struct{}

// GetUserByID returns a fixed user for testing
func (m *MockRepository) GetUserByID(id int) (*User, error) {
 return &User{ID: id, Name: "Test User"}, nil
}

💡 Mocking lets us test service logic independently, without setting up a real database.

Step 5: Write Table-Driven Tests for the Service Layer

📂 service/user_service_test.go

package service

import (
 "example.com/repository"
 "testing"
)

// TestGetUserByID tests the UserService
func TestGetUserByID(t *testing.T) {
 mockRepo := &repository.MockRepository{}
 service := NewUserService(mockRepo)

 tests := []struct {
  id       int
  expected string
 }{
  {1, "User: Test User"},
  {2, "User: Test User"},
 }

 for _, tt := range tests {
  result, err := service.GetUserByID(tt.id)
  if err != nil || result != tt.expected {
   t.Errorf("Expected %s, got %s", tt.expected, result)
  }
 }
}

How Table-Driven Tests Work

The tests array contains multiple test cases.
We loop over them, making our test scalable and easy to extend.

Step 6: Run the Tests

Run the unit tests:

go test ./service -v

🎉 Success! We’ve written testable code and verified it works.

Best Practices for Writing Testable Code

Use Dependency Injection → Avoid hardcoded dependencies.

Use Interfaces → Abstract implementations for flexibility.

Mock External Services → No real DB/API calls in unit tests.

Write Table-Driven Tests → Scalable test cases.

Separate Concerns → Business logic ≠ Database logic.

Final Thoughts

Writing testable code in Go isn’t just about testing — it’s about building better software.

By following these principles, we’ll write modular, maintainable, and scalable code that’s a joy to work with.

------------------------------------------------------------------------------------------------------------

Need expert Golang developers? At Go Cloud Studio, we provide on-demand Golang developers and end-to-end Golang software development services.