How to Run Tests for the no-mistakes Project: Commands and Workflows

Run make check to execute the complete verification pipeline, or use go test -race ./... for fast unit tests and make e2e for build-tagged end-to-end validation.

The no-mistakes project is a Go-based daemon and CLI tool that relies on a comprehensive test suite to verify concurrency safety and pipeline correctness. Whether you are contributing new features or verifying local changes, understanding how to run tests for the no-mistakes project ensures you catch race conditions and integration failures before they reach production.

Prerequisites

Before executing any test commands, ensure you have Go installed and the repository cloned. The test suite is designed to run hermetically: it automatically resets global state and uses temporary directories rather than touching your actual ~/.no-mistakes configuration.

Running Unit and Integration Tests

The core test suite uses the standard Go testing framework with race detection enabled by default to catch concurrent data access issues in the daemon's goroutines.

Execute All Unit Tests

To run every *_test.go file across the repository, including tests in internal/daemon/, internal/db/, and internal/pipeline/steps/, execute:

go test -race ./...

This command recursively tests all packages while the -race flag detects data races in the concurrency-heavy daemon implementation located in internal/daemon/daemon.go.

Test Specific Packages

For targeted feedback during development, narrow the scope to individual packages:


# Test only the database layer

go test -race ./internal/db/...

# Test only the pipeline steps

go test -race ./internal/pipeline/steps/...

Running Linting and Static Analysis

The repository enforces code quality through a Makefile target that wraps go vet and additional linters. To verify static analysis compliance:

make lint

This target, defined in the Makefile, ensures consistent formatting and catches common Go coding errors before they are committed to the codebase.

Running End-to-End Tests

End-to-end tests validate the complete workflow including Git hooks, agent sessions, and the daemon lifecycle. These tests live in internal/e2e/ and require the e2e build tag to isolate them from fast unit tests.

To execute the full e2e suite:

make e2e

This command compiles the test harness with the e2e tag, creates isolated temporary Git repositories, and exercises the pipeline against real-world scenarios. The implementation in internal/e2e/ resets global state and uses temporary NM_HOME directories to ensure tests remain hermetic and do not interfere with your local environment.

Running the Full Verification Suite

For CI/CD pipelines or pre-commit validation, the check target runs the complete sequence: formatting, linting, unit tests, and end-to-end tests.

make check

According to the Makefile source, this orchestrates the entire validation workflow in a single command, ensuring the codebase passes all quality gates before submission.

Summary

  • Use go test -race ./... to run unit tests with race detection across all packages including internal/daemon/ and internal/db/.
  • Use make lint to execute static analysis defined in the Makefile.
  • Use make e2e to run build-tagged end-to-end tests that validate the full daemon and agent lifecycle in internal/e2e/.
  • Use make check for the complete verification pipeline combining all test stages.
  • Individual packages can be tested by appending their path to go test -race, such as ./internal/pipeline/steps/....

Frequently Asked Questions

How do I run only the end-to-end tests?

Run make e2e from the repository root. This target compiles tests with the e2e build tag and executes the integration suite in internal/e2e/ using temporary directories and isolated Git repositories.

Why does the test suite require the -race flag?

The no-mistakes daemon heavily utilizes goroutines for concurrent agent operations. The -race flag enables Go's race detector to catch data races during testing, which is critical for verifying thread safety in internal/daemon/daemon.go and related components.

Can I run tests without affecting my existing no-mistakes configuration?

Yes. The test harness automatically sets NM_HOME to temporary directories during execution. According to the test implementations in internal/db/db_test.go and the e2e suite, all state is reset between runs, ensuring your actual ~/.no-mistakes directory remains untouched.

What is the difference between make test and go test ./...?

While go test ./... runs the standard Go test runner, the Makefile targets wrap these commands with additional configuration, including race detection flags, environment variable setup, and prerequisite steps like linting. The Makefile provides the canonical interface for running the full test suite.

Have a question about this repo?

These articles cover the highlights, but your codebase questions are specific. Give your agent direct access to the source. Share this with your agent to get started:

Share the following with your agent to get started:
curl -s "https://instagit.com/install.md"

Works with
Claude Codex Cursor VS Code OpenClaw Any MCP Client

Maintain an open-source project? Get it listed too →