How to Run All Go Tests in a Project with go test

By the end of this page, you will understand how go test works with Go packages, how to run tests across an entire project, and why commands like go test ./... are commonly used in real Go codebases.

In Go, go test works at the package level, not by manually searching for individual *_test.go files.

That means when you run:

go test

Go tests the package in the current directory only.

If your project contains multiple packages in subdirectories, those tests are not automatically included unless you tell Go to test more than one package.

The common solution is:

go test ./...

The pattern ./... means:

• start from the current directory
• include the current package
• include all subpackages recursively

This matters because most real Go projects are split into multiple packages such as:

• ./api
• ./db
• ./internal/auth
• ./utils

Each of those directories may contain its own *_test.go files. Using go test ./... ensures all package tests are run in one command.

This package-based model is an important part of how Go organizes code, builds software, and runs tests.

Think of a Go project as a building with many rooms.

• Each directory/package is one room.
• go test checks only the room you are currently standing in.
• go test ./... walks through the current room and then opens every room inside the building beneath it.

So the command is not saying “find test files manually.” It is saying “test every package starting here.”

The main syntax is:

go test ./...

Example project structure

myapp/
├── go.mod
├── main.go
├── main_test.go
├── api/
│   ├── handlers.go
│   └── handlers_test.go
├── db/
│   ├── store.go
│   └── store_test.go
└── internal/
    └── auth/
        ├── auth.go
        └── auth_test.go

Commands

Test only the current directory:

go test

Test all packages from the current directory downward:

go test ./...

Test with verbose output:

go test -v ./...

Test without using cached results:

go test -count=1 ./...

What happens

• go test runs tests in the current package only.
• go test ./... runs tests in the current package and all nested packages.
• Go automatically detects *_test.go files inside each package.

You do not need to list test files manually.

Consider this structure:

project/
├── math/
│   ├── add.go
│   └── add_test.go
└── stringutil/
    ├── trim.go
    └── trim_test.go

If you are inside project/ and run:

go test

Step by step

1. Go looks at the current directory: project/
2. It checks whether project/ itself is a Go package with testable files.
3. It does not automatically enter math/ or stringutil/.
4. Tests in subdirectories are skipped.

Now run:

go test ./...

Step by step

1. ./... tells Go to start at the current directory.
2. Go finds all packages under that path.
3. It includes ./math.
4. It includes ./stringutil.
5. For each package, Go compiles the package and its tests.
6. It runs all matching test functions such as TestAdd and TestTrim.
7. It prints a result for each package.

Typical output may look like:

ok   	project/math	0.003s
ok   	project/stringutil	0.002s

This is why ./... is the standard way to test an entire Go project.

Running tests across all packages is useful in many everyday situations:

• Before committing code: make sure no package was broken by your changes.
• In CI pipelines: GitHub Actions, GitLab CI, and other tools commonly run go test ./....
• During refactoring: if you rename functions or move shared logic, you want all package tests to run.
• In monorepo-style Go services: multiple internal packages need to be tested together.
• Before release: verify the full project still behaves correctly.

Example CI command:

go test ./...

Example with more detail:

go test -v ./...

Example for a fresh run:

go test -count=1 ./...

In real Go codebases, developers rarely run tests file by file. Instead, they use package patterns and flags.

Common patterns include:

• Test everything

  go test ./...
  

• Verbose output for debugging CI failures

  go test -v ./...
  

• Disable cache when investigating flaky behavior

  go test -count=1 ./...
  

• Run only tests matching a name

  go test ./... -run TestLogin
  

• Collect coverage across packages

  go test ./... -cover
  

Developers also organize tests by package boundaries. This means each folder usually owns its own tests, and one top-level command runs them all.

This style fits well with:

• modular package design
• automated validation in CI
• safe refactoring
• quick feedback loops during development

1. Expecting go test to recurse automatically

Broken assumption:

go test

Many beginners expect this to test every folder. It does not. It only tests the current package.

Use:

go test ./...

2. Thinking Go searches only by filename

Go does not simply scan the filesystem for *_test.go files and run them independently. Test files belong to a package and are run as part of that package.

3. Running from the wrong directory

If you run:

go test ./...

from a subdirectory, Go starts there, not from the project root.

To test the full project, run the command from the module or project root when appropriate.

4. Confusing packages with folders that are not Go packages

A directory is only tested if it is a valid Go package. Random folders without Go files are ignored.

5. Forgetting about cached test results

Sometimes you change environment-dependent behavior and wonder why tests seem unchanged.

Use:

go test -count=1 ./...

to force a fresh run.

6. Using shell glob patterns instead of Go package patterns

This is not the normal Go way:

go test ./*

That depends on shell expansion and is not the same as Go's recursive package pattern.

Prefer:

go test ./...

go test vs go test ./...

• Use go test when you only care about the current package.
• Use go test ./... when you want project-wide coverage.

./... vs shell globs

• ./... is a Go package pattern.
• ./* is usually a shell expansion.
• For recursive Go testing, ./... is the standard and reliable choice.

# Test current package only
go test

# Test current package explicitly
go test .

# Test current package and all subpackages
go test ./...

# Verbose output
go test -v ./...

# Disable test cache
go test -count=1 ./...

# Run only matching test names
go test ./... -run TestName

# Run with coverage
go test ./... -cover

Rules to remember

• Go tests packages, not standalone test files.
• *_test.go files are included automatically within each package.
• go test is not recursive.
• go test ./... is recursive from the current directory.
• Run from the correct project or module root when you want the whole project.

Most important answer

go test ./...

How do I run all tests in a Go project?

Use:

go test ./...

This runs tests in the current directory and all subpackages.

Does go test automatically include subdirectories?

No. By itself, go test only runs tests for the current package.

What does ./... mean in Go?

It is a package pattern meaning the current directory and everything below it recursively.

Do I need to specify *_test.go files manually?

No. Go automatically finds and runs test files inside each package.

Why are some folders not being tested?

A folder must contain a valid Go package to be tested. Non-Go folders are ignored.

How do I rerun all tests without cached results?

Use:

go test -count=1 ./...

Can I run all tests with verbose output?

Yes:

go test -v ./...

Should I run this command from the project root?

Usually yes, if you want to test the entire module or project tree.

• Go packages — go test operates on packages, so understanding package structure is essential.
• Go modules — modules define the project boundary and are often the root from which tests are run.
• Go test files — *_test.go naming controls which files are included in tests.
• Go test flags — flags like -v, -run, -cover, and -count are commonly used with project-wide testing.
• Code coverage in Go — useful when measuring how much of your project is exercised by tests.
• Continuous integration — CI systems often run go test ./... automatically on every change.