Quality and Generation Commands

The go command includes several subcommands that do not directly build or run code but instead check its quality, enforce consistency, and generate new source files. The four most commonly used are go test, go vet, go fmt, and go generate. Together they form a feedback loop: format the code, check it for subtle bugs, verify it with tests, and automate the boring parts of writing repetitive code.

How go test Runs Tests

go test is Go's built-in test runner. It looks for files ending in _test.go, compiles them together with the package under test, and executes any function whose name starts with Test. The command does not need an external test framework; the testing package from the standard library provides everything required to write and report test results.

A typical test file looks like this:

package math
import "testing"
func TestAdd(t *testing.T) {
    got := Add(2, 3)
    want := 5
    if got != want {
        t.Errorf("Add(2, 3) = %d; want %d", got, want)
    }
}

Running go test in the directory that contains this file compiles a test binary, runs it, and prints a summary. When the test passes, the output is minimal:

ok  	example.com/math	0.003s

If a test fails, you see the file, line number, and the message you passed to t.Errorf. There is no magic — the testing.T value you receive in every test function is the single point of contact with the runner. Methods like Errorf, Fatalf, Skip, and Parallel give you control over failure semantics and test isolation.

Why the Testing Framework Is Built Into the Language

Many languages treat testing as an external library. Go integrates it into the toolchain so that every developer has the same test runner, the same output format, and the same expectations. There is no debate about which assertion library to use; the standard pattern is to compare values with if statements and call t.Error or t.Fatal. This uniformity makes test code immediately understandable across projects and reduces the cognitive cost of contributing to unfamiliar codebases.

Common Workflow and Flags

You rarely run go test on a single package in isolation. The real workflow involves running tests across the entire module, often with flags that change caching behavior or add race detection.

# Run all tests in the current module and subdirectories
go test ./...

The ./... pattern tells Go to start in the current directory and recursively find all packages. This is the command you will run most often before committing code.

Two flags worth knowing early:

• -v prints the name and result of each test function, not just the package summary. It is helpful when you want to see which specific test failed without scrolling through the file.
• -count=1 disables test caching. By default, if a package's code and tests have not changed, go test reuses the previous result. Adding -count=1 forces a fresh run, which is useful when you suspect a flaky test or an external dependency has changed.

go test -v -count=1 ./...

A First Mental Model for Testing in Go

Think of go test as a tiny build system for test binaries. For every package you ask it to test, it compiles a temporary executable that contains the package's code plus all _test.go files. It then runs that executable and captures the exit code. The test functions themselves are ordinary Go functions that the runner discovers via reflection on the compiled binary. This means test code has access to the same memory, the same imports, and the same concurrency model as production code — there is no separate test runtime.

A common beginner mistake is placing test helper functions in a file that does not end with _test.go. Those functions will be compiled into the production binary if the package is built, and they may accidentally expose testing internals. Always keep helper code that uses testing.T inside a _test.go file.

How go vet Catches Subtle Bugs

go vet runs a set of static analysis checks on your code. It examines source files for patterns that are technically valid Go but are almost certainly mistakes. The compiler will not reject them, but a human reviewer would flag them immediately.

Consider a function that uses fmt.Sprintf but ignores the return value:

func greet(name string) {
    fmt.Sprintf("Hello, %s", name)
}

This compiles without error. go vet reports it:

./main.go:5:2: fmt.Sprintf call has possible formatting directive %s, but result is not used

The tool knows that fmt.Sprintf is a pure function whose only purpose is the formatted string it returns. Calling it without using the result is a dead giveaway of a mistake — likely the developer meant fmt.Printf to actually print the greeting.

go vet ships with a curated set of checks. You do not need to install anything extra. Over time, the Go team adds new checks that catch real-world bugs found in large codebases. This is why running go vet is part of the pre-commit checklist in most Go projects.

How vet Works Under the Hood

Unlike a linter that parses source text, go vet operates on Go's type-checked abstract syntax tree. Each check is a small function that walks the AST looking for a specific pattern. For example, the printf check inspects every call expression whose function is fmt.Sprintf, fmt.Fprintf, or similar, and compares the format string against the argument types. If the number or type of arguments does not match the format verbs, it reports a problem.

Because vet has access to full type information, it can catch errors that a simple text pattern would miss. A %d with a string argument is flagged; %s with an int is flagged. But %v is intentionally flexible and won't trigger a warning.

Integrating vet Into a Workflow

You can run vet on the entire module just like tests:

go vet ./...

The output is silent when there are no issues. If vet prints anything, treat it as a bug. Do not suppress vet warnings with comments unless you thoroughly understand why the pattern is a false positive in your specific context.

The Mental Model for Static Analysis

Think of the Go compiler as the first gate: it rejects code that cannot run. go vet is the second gate: it rejects code that can run but shouldn't. The compiler cares about syntax and types. Vet cares about intent. It encodes the collective experience of the Go community about which mistakes are both common and mechanically detectable.

Vet will not replace a human reviewer. It will never understand your business logic. But it will catch an entire category of errors — mismatched format strings, unreachable code, incorrect uses of locks — before they reach production.

How go fmt Removes Style Decisions

go fmt rewrites Go source files to match the standard formatting rules. It does not ask for your preferences. It does not have a configuration file. It applies the same indentation, spacing, and line breaking to every file it touches.

The command is typically run on a whole module:

go fmt ./...

Any file with formatting deviations gets rewritten in place. Files that already conform are left untouched. The output tells you which files were modified:

main.go
pkg/helper.go

The formatting rules are baked into the gofmt tool that go fmt calls under the hood. These rules were designed early in Go's history and have remained stable. The result is that every Go codebase looks familiar within minutes, regardless of who wrote it.

Why Opinionated Formatting Matters

The value of go fmt is not that the chosen style is perfect — it's that the style is uniform. No team ever spends time debating tabs versus spaces or where to place braces. Code reviews never contain comments about formatting. When you open a pull request on an unfamiliar project, the code looks like yours, and you can focus on logic rather than layout.

This uniformity also makes tooling more reliable. Static analysis tools, diff algorithms, and code generators can rely on a consistent AST structure because the source always conforms to the same layout rules.

What Beginners Often Misunderstand

A common first reaction is to run go fmt manually before each commit. That works, but the better approach is to let your editor run it automatically on save. Most Go editor plugins do this by default. If yours does not, configure it; manual formatting is a step you will eventually forget.

Another point of confusion: go fmt formats only files that are part of the current module. If you have a Go file outside a module (no go.mod in its directory tree), go fmt may still work on it, but the reliable way is to always work inside a module.

How go generate Automates Repetitive Code

go generate is not a code generator itself. It is a command that scans Go source files for special comments and executes arbitrary commands found in those comments. The commands can do anything — generate Go source files, update assets, compile protocol buffers — but the most common use is producing boilerplate code that would be tedious to write and maintain by hand.

A directive looks like a comment in a regular .go file:

//go:generate stringer -type=Status
type Status int
const (
    StatusPending Status = iota
    StatusActive
    StatusDone
)

The //go:generate prefix is immediately followed by a command and its arguments. There is no space between // and go:generate. The directive tells the go generate tool: when you process this file, run stringer -type=Status in this package directory.

The stringer tool (which ships with Go but must be installed separately) reads the type definition and generates a String() method that returns the constant name. Without code generation, you would write that method by hand and update it every time you add a constant. With go generate, you add one line of comment and run a single command.

Running go generate

The generator runs at the root of the module:

go generate ./...

This tells Go to scan every package, find all //go:generate directives, and execute each one. The commands are executed in the order they appear in each file, and files are processed in lexical order within a package.

A Step-by-Step Example

Here's how you would use go generate to keep a String method in sync with an enum type.

go install golang.org/x/tools/cmd/stringer@latest

package task
//go:generate stringer -type=Status
type Status int
const (
    StatusPending Status = iota
    StatusActive
    StatusDone
)

go generate ./...

func (i Status) String() string {
    // ...
}

What go generate Is Not

It is not a build system. Directives are never executed automatically during go build or go run. You must run go generate explicitly. This separation exists because many generators have external dependencies (like protoc for Protocol Buffers) that not every developer needs to have installed. By keeping generation a deliberate, manual step, the build stays fast and self-contained.

Common Mistakes with go generate

The most frequent error is adding a space between // and go:generate:

// go:generate stringer -type=Status

This is an ordinary comment. The go tool will ignore it, and no code will be generated. The directive must be //go:generate with no space after the slashes.

Another mistake is forgetting that go generate runs commands in the package directory, not the module root. If your generator expects a specific configuration file, place that file where the directive lives or use relative paths carefully.

How These Commands Fit Together

Individually, each command solves a narrow problem. Together, they create a development loop that catches errors at multiple levels:

• go fmt removes surface-level noise.
• go vet catches semantic mistakes the compiler won't flag.
• go test verifies that the code behaves as expected.
• go generate eliminates the manual work of writing and updating boilerplate.

A common pre-commit workflow runs all four:

go fmt ./...
go vet ./...
go test ./...
go generate ./...

If go generate produces changes, you commit them alongside the source modifications. If any step fails, you fix the problem before pushing. This loop is simple enough to memorize, and it catches a broad range of issues before they reach a teammate or a CI pipeline.