# How to Execute Go Test for All Tests in a Go Project > Efficiently execute all Go tests in your project with go test ./... Run tests across all packages using parallelism and caching from your module root. - Repository: [Go/go](https://github.com/golang/go) - Tags: how-to-guide - Published: 2026-02-16 --- **The most efficient way to execute all tests in a Go project is to run `go test ./...` from the module root, which automatically discovers and runs tests across all packages with built-in parallelism and caching.** When working with the `golang/go` repository or any Go module, you need a reliable method to validate your entire codebase. The Go toolchain provides a purpose-built solution that eliminates manual package enumeration while optimizing for execution speed through intelligent caching and parallel processing. ## Understanding the `go test ./...` Command The `./...` pattern is a **package pattern** that recursively matches all packages rooted at the current directory. When you execute: ```bash go test ./... ``` The command traverses your module tree, identifies every `*_test.go` file, and executes the test functions within them. This pattern is resolved by the module loading system in [`src/cmd/go/internal/modload/query.go`](https://github.com/golang/go/blob/main/src/cmd/go/internal/modload/query.go), which expands the ellipsis notation into a concrete list of packages to test. ## Internal Architecture of the Go Test Driver The `go test` command is implemented in [`src/cmd/go/internal/test/test.go`](https://github.com/golang/go/blob/main/src/cmd/go/internal/test/test.go). This driver handles flag parsing, package traversal, and orchestration of test execution. The workflow follows this sequence: 1. **Package Discovery**: The driver uses `./...` expansion to identify all packages in the module boundary. 2. **Binary Construction**: For each package, the driver invokes the build logic in [`src/cmd/go/internal/work/build_test.go`](https://github.com/golang/go/blob/main/src/cmd/go/internal/work/build_test.go) to compile a separate test binary. 3. **Execution**: The compiled binaries are executed by the logic in [`src/cmd/go/internal/work/exec.go`](https://github.com/golang/go/blob/main/src/cmd/go/internal/work/exec.go), which manages process isolation and output capture. This architecture ensures that tests run in isolated processes, preventing one package's test failure from corrupting another's execution environment. ## Performance Optimization Strategies ### Parallel Execution Across Packages By default, `go test` runs tests for different packages in parallel. The concurrency level is controlled by the `-p` flag, which defaults to the number of logical CPUs (`GOMAXPROCS`). To explicitly limit parallelism to 4 concurrent packages: ```bash go test -p 4 ./... ``` This parallelization happens at the package level, while individual tests within a package run sequentially by default (unless marked with `t.Parallel()`). ### Test Result Caching The Go toolchain caches successful test results in `$GOCACHE` to avoid redundant execution. When you run tests repeatedly without changing source code or test files, the driver retrieves results from [`src/cmd/go/internal/cache/cache_test.go`](https://github.com/golang/go/blob/main/src/cmd/go/internal/cache/cache_test.go) (the cache implementation) instead of re-executing binaries. To bypass caching for a specific run: ```bash go test -count=1 ./... ``` Or clear the entire test cache: ```bash go clean -testcache ``` ### Selective Test Execution When debugging specific functionality, use the `-run` flag with a regular expression to execute only matching test functions: ```bash go test -run TestSpecificFunction ./... ``` This avoids the overhead of running the entire suite while maintaining the same command structure. ### Race Detection and Coverage Integration For comprehensive validation, combine the `./...` pattern with analysis flags: ```bash # Detect data races go test -race ./... # Generate coverage profile go test -coverprofile=coverage.out ./... # Output structured JSON for CI pipelines go test -json ./... > test-report.json ``` The `-race` flag triggers the data-race detector, which the driver links automatically via [`src/cmd/go/internal/work/build_test.go`](https://github.com/golang/go/blob/main/src/cmd/go/internal/work/build_test.go). ## Practical Workflow Examples **Standard development cycle:** ```bash # Fast feedback during development go test ./... # Verbose output for debugging failures go test -v ./... # Pre-commit validation with race detection go test -race -count=1 ./... ``` **CI/CD pipeline integration:** ```bash # Generate machine-readable report with coverage go test -json -coverprofile=cover.out ./... > results.json # Verify specific package subsets go test ./internal/... ./pkg/... ``` ## Key Source Files in the Go Toolchain | File | Role | |------|------| | [`src/cmd/go/internal/test/test.go`](https://github.com/golang/go/blob/main/src/cmd/go/internal/test/test.go) | Core implementation of `go test` – flag parsing, package traversal, and test binary orchestration | | [`src/cmd/go/internal/work/build_test.go`](https://github.com/golang/go/blob/main/src/cmd/go/internal/work/build_test.go) | Logic for compiling test binaries and linking test dependencies | | [`src/cmd/go/internal/modload/query.go`](https://github.com/golang/go/blob/main/src/cmd/go/internal/modload/query.go) | Package pattern resolution (handles `./...` expansion) | | [`src/cmd/go/internal/cache/cache_test.go`](https://github.com/golang/go/blob/main/src/cmd/go/internal/cache/cache_test.go) | Test result caching implementation for faster repeated runs | | [`src/cmd/go/internal/work/exec.go`](https://github.com/golang/go/blob/main/src/cmd/go/internal/work/exec.go) | Execution of compiled test binaries and output management | ## Summary - **`go test ./...`** is the canonical command to execute all tests in a Go project, leveraging recursive package discovery. - The test driver in [`src/cmd/go/internal/test/test.go`](https://github.com/golang/go/blob/main/src/cmd/go/internal/test/test.go) automatically parallelizes execution across packages up to `GOMAXPROCS` and caches results in `$GOCACHE`. - Isolated test binaries prevent cross-package contamination while maximizing throughput. - Flags like `-race`, `-cover`, and `-json` extend the basic command for comprehensive CI/CD integration without sacrificing performance. ## Frequently Asked Questions ### What does the `./...` pattern mean in go test? The `./...` pattern is a wildcard notation that matches all Go packages recursively starting from the current directory. According to the implementation in [`src/cmd/go/internal/modload/query.go`](https://github.com/golang/go/blob/main/src/cmd/go/internal/modload/query.go), the three dots expand to include every subdirectory containing Go source files, making it unnecessary to manually list individual package paths. ### How do I run tests for a specific package only? To test a specific package, provide its import path relative to the module root instead of `./...`. For example, `go test ./internal/auth` runs only the tests in the `internal/auth` directory. You can also test multiple specific packages by listing them separated by spaces: `go test ./pkg/... ./cmd/...`. ### Why are my tests not running in parallel? By default, `go test` runs different packages in parallel (up to the number of CPUs), but tests within a single package run sequentially. To enable parallel execution of individual tests, you must call `t.Parallel()` inside your test functions. Additionally, if you set `-p 1`, the tool forces sequential package execution. ### How do I disable test caching in Go? To bypass the test cache for a single execution, use the `-count=1` flag: `go test -count=1 ./...`. This forces the test driver in [`src/cmd/go/internal/test/test.go`](https://github.com/golang/go/blob/main/src/cmd/go/internal/test/test.go) to rebuild and rerun tests regardless of cache state. To permanently clear all cached test results, run `go clean -testcache` before your next test execution.