Testability Blind Scorecard — 51 Go Projects#

Rubric#

#TraitDefinition0 (absent)1 (weak)2 (clear)3 (textbook)
U1Hermetic by constructionSuite reaches correctness without Docker, GPUs, external services, or live networkRequires Docker compose or external services for unit-level testsSome unit tests hermetic, integration needs containersMost layers hermetic, only top-tier E2E needs real infraEntire suite (including integration) runs in-process with no external deps
U2Exported test-helper packageProject ships pkg/test (or equivalent) for downstream users to test code that depends on itNone; internal test helpers onlyAn ad-hoc helper file or two, not versionedA test package exists but is partial or undocumentedPublic, versioned pkg/test (or equivalent), used by both project and downstream users
U3Low mock burdenReal implementations preferred over mocks; mocks confined to external boundariesPervasive generated mocks across internal seams; mock-everything styleMany internal mocks, some real implsMocks at external boundaries; internal collaborators usually realNo mocks for internal collaborators; “real implementations are the test implementations”
U4Conformance / acceptance suite for replaceable partsGeneric, parameterized test suite that every backend/plugin/implementation must passNoneA few shared assertions but no formal suiteA conformance suite exists for one subsystemMultiple subsystems have generic acceptance suites parameterized over implementations
U5DSL / declarative case formatTest cases expressed as data (files, tables, structs interpreted by a runner) rather than imperative codeImperative test functions onlySome table-driven tests, no DSLHeavy table-driven style; one DSL or declarative format usedMultiple declarative formats used heavily; tests scale by adding files/rows
U6Goroutine-leak hygieneFirst-class checks for goroutine leaks (goleak, leaktest) integrated into the suiteNoneOne or two opportunistic usesUsed in most relevant packagesUsed pervasively as a correctness property; failures fail the test

State the rubric verbatim BEFORE scoring any project. The rubric is fixed; do not adapt it per project.

Scorecard#

ProjectU1U2U3U4U5U6Composite
P01-kubernetes2120207
P02-moby1120206
P03-etcd21222211
P04-prometheus22223213
P05-grafana1110205
P06-hugo31303010
P07-traefik1121207
P08-caddy2120207
P09-cockroach22233315
P10-fyne23302010
P11-minio2020206
P12-consul1210206
P13-vault2120207
P14-terraform2120207
P15-nomad2120207
P16-dapr2120207
P17-k3s1110205
P18-helm2220208
P19-istio1120206
P20-argo-cd1110205
P21-tekton-pipeline2120207
P22-go33323014
P23-gin2230209
P24-echo2230209
P25-fiber3030208
P26-buffalo2020105
P27-beego1210206
P28-gorm2120207
P29-sqlc2030308
P30-viper3030208
P31-cobra3030208
P32-fzf2030207
P33-gh2120207
P34-gitea1120206
P35-gogs1010204
P36-drone1010204
P37-buildkite-agent2020206
P38-restic2122209
P39-syncthing2010205
P40-rclone21232010
P41-frp1120206
P42-headscale2121208
P43-tailscale2120207
P44-wireguard-go32302212
P45-delve1132209
P46-air1020205
P47-pop1021105
P48-pocketbase33303012
P49-nats-server2130107
P50-temporal2101206
P51-crush3130209

Evidence#

Evidence is grouped by project. Prefix report: indicates the citation draws from the project’s --testing.md Phase 1 report.

P01-kubernetes#

  • P01-kubernetes / U1 (score 2): report:P01-kubernetes--testing.md — Unit and integration tests use in-process fakes; only E2E tests in test/e2e/ require a real cluster via kubetest2.
  • P01-kubernetes / U2 (score 1): report:P01-kubernetes--testing.md — k8s.io/apiserver/pkg/testing, k8s.io/client-go/testing, and similar exist as test helpers but are internal to the Kubernetes ecosystem, not versioned standalone packages.
  • P01-kubernetes / U3 (score 2): report:P01-kubernetes--testing.md — Extensive mock infrastructure (mockgen, k8s.io/client-go/testing FakeClient) exists but is focused on the API boundary layer; internal components use real implementations.
  • P01-kubernetes / U5 (score 2): report:P01-kubernetes--testing.md — Heavy table-driven tests throughout; testscript for CLI tests; structured test case slices across most packages.

P02-moby#

  • P02-moby / U1 (score 1): report:P02-moby--testing.md — Unit tests are hermetic in-process; integration tests in integration/ require a real Docker daemon and optionally containers.
  • P02-moby / U2 (score 1): report:P02-moby--testing.md — testutil/ directory provides internal helpers; no versioned public pkg/test for downstream users of Docker libraries.
  • P02-moby / U3 (score 2): report:P02-moby--testing.md — Mock infrastructure exists for API layer; internal daemon components tested with real implementations.
  • P02-moby / U5 (score 2): report:P02-moby--testing.md — Table-driven tests prevalent throughout; structured scenario slices for API and integration tests.

P03-etcd#

  • P03-etcd / U1 (score 2): report:P03-etcd--testing.md — Unit and integration tests run in-process with embedded etcd nodes; only full E2E needs multiple external processes.
  • P03-etcd / U2 (score 1): report:P03-etcd--testing.md — integration/v3client and similar packages exist as test scaffolding but not packaged as downstream-facing helpers.
  • P03-etcd / U3 (score 2): report:P03-etcd--testing.md — Mocks are used at the gRPC and storage backend boundaries; internal logic uses real embedded-cluster implementations.
  • P03-etcd / U4 (score 2): report:P03-etcd--testing.md — mvcc/backend has parameterized backend tests running against multiple store implementations; storage interface conformance enforced via shared test suite.
  • P03-etcd / U5 (score 2): report:P03-etcd--testing.md — Widespread table-driven tests; integration test scenarios expressed as structured Go slices.
  • P03-etcd / U6 (score 2): report:P03-etcd--testing.md — go.uber.org/goleak integrated into the test suite; goroutine leak checks present in most server-layer packages.

P04-prometheus#

  • P04-prometheus / U1 (score 2): report:P04-prometheus--testing.md — Unit tests and most integration tests run fully in-process; only remote storage end-to-end tests require external services.
  • P04-prometheus / U2 (score 2): report:P04-prometheus--testing.md — prometheus/client_golang/prometheus/testutil is an exported test helper package widely used by downstream instrumenters; model/rulefmt/testdata patterns also exported.
  • P04-prometheus / U3 (score 2): report:P04-prometheus--testing.md — Rule engine and TSDB tested with real in-process implementations; mock interfaces used only at remote read/write boundaries.
  • P04-prometheus / U4 (score 2): report:P04-prometheus--testing.md — Storage interface (storage.Storage) has a shared storage/testing test suite that every storage backend (TSDB, remote, exemplar) must pass; conformance enforced.
  • P04-prometheus / U5 (score 3): report:P04-prometheus--testing.md — Heavy table-driven tests across all packages; testscript for promtool CLI; .rules and .yml golden files loaded as declarative test cases for rule evaluation.
  • P04-prometheus / U6 (score 2): report:P04-prometheus--testing.md — go.uber.org/goleak used across the scrape and query engine packages; goroutine leak assertions integrated in most concurrency-heavy test files.

P05-grafana#

  • P05-grafana / U1 (score 1): report:P05-grafana--testing.md — Many integration tests require a running Grafana instance, PostgreSQL, or external datasources; only basic unit tests are fully hermetic.
  • P05-grafana / U2 (score 1): report:P05-grafana--testing.md — Internal test helpers exist but no versioned public test package for plugin or datasource authors.
  • P05-grafana / U3 (score 1): report:P05-grafana--testing.md — Generated mocks used extensively for datasource and store interfaces across internal packages; not confined to external boundaries.
  • P05-grafana / U5 (score 2): report:P05-grafana--testing.md — Table-driven tests present throughout; some golden file assertions for API responses.

P06-hugo#

  • P06-hugo / U1 (score 3): report:P06-hugo--testing.md — Entire test suite, including rendering integration tests, runs in-process using an in-memory filesystem (afero.MemMapFs). No Docker, no external services, no network calls.
  • P06-hugo / U2 (score 1): report:P06-hugo--testing.md — hugolib.IntegrationTestBuilder and htesting packages exist but are not versioned or documented for downstream theme/extension authors.
  • P06-hugo / U3 (score 3): report:P06-hugo--testing.md — No mock framework; the in-memory filesystem (afero.MemMapFs) IS the test implementation of the FS abstraction. Real Hugo pipelines run against in-memory data.
  • P06-hugo / U5 (score 3): report:P06-hugo--testing.md — IntegrationTestBuilder takes embedded TOML configs and site content as Go raw string literals (a site-in-a-string DSL); plus heavy table-driven tests; content files interpreted by a runner.

P07-traefik#

  • P07-traefik / U1 (score 1): report:P07-traefik--testing.md — Unit tests are hermetic; E2E integration tests spin up Docker-compose or real backend containers.
  • P07-traefik / U2 (score 1): report:P07-traefik--testing.md — pkg/testhelpers/ package contains test utilities but is not versioned for middleware or plugin authors.
  • P07-traefik / U3 (score 2): report:P07-traefik--testing.md — Provider and middleware tests use real implementations; some generated mocks at provider/backend interfaces.
  • P07-traefik / U4 (score 1): report:P07-traefik--testing.md — Some shared assertion helpers across provider tests; no formal generic conformance suite that every provider must pass.
  • P07-traefik / U5 (score 2): report:P07-traefik--testing.md — Table-driven tests used throughout configuration and middleware packages.

P08-caddy#

  • P08-caddy / U1 (score 2): report:P08-caddy--testing.md — Most tests run in-process with real Caddy servers on loopback; only TLS integration tests require network-accessible external services.
  • P08-caddy / U2 (score 1): report:P08-caddy--testing.md — caddytest package provides test helpers; it is part of the caddy module but not explicitly documented as a downstream-facing versioned interface.
  • P08-caddy / U3 (score 2): report:P08-caddy--testing.md — Module tests use real Caddy instances; mocks are limited to a few specific external service boundaries.
  • P08-caddy / U5 (score 2): report:P08-caddy--testing.md — Table-driven tests throughout; Caddyfile-as-config strings in test cases form a quasi-declarative format.

P09-cockroach#

  • P09-cockroach / U1 (score 2): report:P09-cockroach--testing.md — Unit and most integration tests run in-process using embedded CockroachDB nodes; full cluster acceptance tests require external cluster resources.
  • P09-cockroach / U2 (score 2): report:P09-cockroach--testing.md — testutils/ and testutils/sqlutils exported packages provide test helpers; documented for use within the CockroachDB test ecosystem.
  • P09-cockroach / U3 (score 2): report:P09-cockroach--testing.md — Internal components tested with real in-process implementations; mocks used only at external I/O and storage interface boundaries.
  • P09-cockroach / U4 (score 3): report:P09-cockroach--testing.md — Generic KV conformance tests in storage/ that every storage engine (Pebble, RocksDB) must pass; SQL executor conformance tests parameterized over dialect variants; multiple subsystems covered.
  • P09-cockroach / U5 (score 3): report:P09-cockroach--testing.md — Heavy table-driven tests; TestLogic file-based SQL test format (logic tests load .sql files and assert output line-by-line); multiple declarative formats used at scale.
  • P09-cockroach / U6 (score 3): report:P09-cockroach--testing.md — go.uber.org/goleak (or equivalent leaktest) used pervasively; goroutine leak assertions integrated as a correctness property throughout server and KV packages.

P10-fyne#

  • P10-fyne / U1 (score 2): report:P10-fyne--testing.md — Software painter renders in-process without GPU/display for most tests; GLFW integration tests use xvfb-run on Linux CI — real virtual framebuffer, not purely in-process.
  • P10-fyne / U2 (score 3): report:P10-fyne--testing.md — fyne.io/fyne/v2/test is a stable, public, versioned package (NewApp, NewCanvas, NewWindow, interaction simulators, golden file assertions) designed for and used by third-party Fyne application developers.
  • P10-fyne / U3 (score 3): report:P10-fyne--testing.md — No mock generator. The test/ package provides full fake implementations of fyne.App, fyne.Driver, fyne.Canvas as concrete structs — real fake implementations, not generated mocks.
  • P10-fyne / U5 (score 2): report:P10-fyne--testing.md — Moderate table-driven tests; 647 calls to AssertRendersToMarkup/AssertRendersToImage constituting a golden-file declarative format as the dominant assertion strategy.

P11-minio#

  • P11-minio / U1 (score 2): report:P11-minio--testing.md — Unit tests run in-process; integration tests start real MinIO servers on loopback ports; no Docker required for most test scenarios.
  • P11-minio / U3 (score 2): report:P11-minio--testing.md — Internal erasure and storage logic tested with real implementations; some mock usage at the S3 API boundary layer.
  • P11-minio / U5 (score 2): report:P11-minio--testing.md — Table-driven tests present throughout; structured scenario slices for S3 API correctness testing.

P12-consul#

  • P12-consul / U1 (score 1): report:P12-consul--testing.md — Unit tests are hermetic; integration tests require a running Consul agent or cluster; Docker used in E2E scenarios.
  • P12-consul / U2 (score 2): report:P12-consul--testing.md — testrpc and testutil packages exist as consul testing helpers; sdk/testutil is documented for external use.
  • P12-consul / U3 (score 1): report:P12-consul--testing.md — Generated mock infrastructure used across agent and service mesh layers; mocking extends well into internal subsystem boundaries.
  • P12-consul / U5 (score 2): report:P12-consul--testing.md — Table-driven tests used across RPC and catalog tests.

P13-vault#

  • P13-vault / U1 (score 2): report:P13-vault--testing.md — Core Vault logic tested in-process; seal, storage, and auth plugin tests run without external services in most cases; HSM and cloud KMS tests require real external infrastructure.
  • P13-vault / U2 (score 1): report:P13-vault--testing.md — vault/testing and helper/testhelpers packages exist; primarily used internally, limited downstream documentation.
  • P13-vault / U3 (score 2): report:P13-vault--testing.md — Auth backends and secrets engines tested with real in-process implementations; some mock usage for audit and storage backends.
  • P13-vault / U5 (score 2): report:P13-vault--testing.md — Table-driven tests used throughout auth method and policy packages.

P14-terraform#

  • P14-terraform / U1 (score 2): report:P14-terraform--testing.md — Core plan/apply logic tested in-process; provider acceptance tests require real cloud credentials; internal/ packages mostly hermetic.
  • P14-terraform / U2 (score 1): report:P14-terraform--testing.md — helper/resource and helper/acctest exported packages for provider acceptance testing; these are downstream-facing but targeted at provider authors, not all Terraform library users.
  • P14-terraform / U3 (score 2): report:P14-terraform--testing.md — Provider interface tested with real provider implementations; mock usage limited to specific backend interface boundaries.
  • P14-terraform / U5 (score 2): report:P14-terraform--testing.md — Table-driven tests throughout; HCL config strings as test case input is a quasi-declarative format.

P15-nomad#

  • P15-nomad / U1 (score 2): report:P15-nomad--testing.md — Scheduler and state store tested in-process; E2E tests require real cluster; most internal packages hermetic.
  • P15-nomad / U2 (score 1): report:P15-nomad--testing.md — testutil/ and helper/testlog packages exist but are not versioned public packages for downstream consumers.
  • P15-nomad / U3 (score 2): report:P15-nomad--testing.md — Scheduler tested with real state store; mocks primarily at driver and client interfaces.
  • P15-nomad / U5 (score 2): report:P15-nomad--testing.md — Table-driven tests across scheduler and allocation packages.

P16-dapr#

  • P16-dapr / U1 (score 2): report:P16-dapr--testing.md — Unit tests in-process; component integration tests require Docker for state stores, pub/sub brokers; most unit layers hermetic.
  • P16-dapr / U2 (score 1): report:P16-dapr--testing.md — dapr/kit/testing and similar packages exist; primarily internal use.
  • P16-dapr / U3 (score 2): report:P16-dapr--testing.md — Component tests use real in-process state and pub/sub implementations where possible; generated mocks at gRPC and component interface boundaries.
  • P16-dapr / U5 (score 2): report:P16-dapr--testing.md — Table-driven tests present throughout binding and state components.

P17-k3s#

  • P17-k3s / U1 (score 1): report:P17-k3s--testing.md — Most meaningful tests require a running K3s cluster or Docker; unit coverage of internal logic is thin.
  • P17-k3s / U2 (score 1): report:P17-k3s--testing.md — Some test helper functions exist but no dedicated exported test package.
  • P17-k3s / U3 (score 1): report:P17-k3s--testing.md — Limited test infrastructure overall; where mocks exist they span internal package boundaries.
  • P17-k3s / U5 (score 2): report:P17-k3s--testing.md — Table-driven tests used in the portions of internal logic that are unit-tested.

P18-helm#

  • P18-helm / U1 (score 2): report:P18-helm--testing.md — Chart rendering and repository tests run in-process; only actual install/upgrade E2E needs a real cluster.
  • P18-helm / U2 (score 2): report:P18-helm--testing.md — helm.sh/helm/v3/pkg/chartutil and helmtest provide exported test utility functions; used by Helm plugin and chart library authors.
  • P18-helm / U3 (score 2): report:P18-helm--testing.md — Kubernetes client mocked at the API boundary; chart rendering engine tested with real in-process logic.
  • P18-helm / U5 (score 2): report:P18-helm--testing.md — Table-driven tests throughout; YAML chart files used as declarative fixtures.

P19-istio#

  • P19-istio / U1 (score 1): report:P19-istio--testing.md — Integration tests require a real Kubernetes cluster with Istio control plane; unit tests for individual components are hermetic but limited in scope.
  • P19-istio / U2 (score 1): report:P19-istio--testing.md — Internal test helpers exist; no versioned public test package for service mesh integrators.
  • P19-istio / U3 (score 2): report:P19-istio--testing.md — Pilot and Envoy xDS tests use generated mocks at the gRPC layer; internal config logic uses real implementations.
  • P19-istio / U5 (score 2): report:P19-istio--testing.md — Table-driven tests used for xDS configuration and policy packages.

P20-argo-cd#

  • P20-argo-cd / U1 (score 1): report:P20-argo-cd--testing.md — Integration tests require a running Kubernetes cluster and ArgoCD installation; unit tests of sync and diff logic are hermetic but thin.
  • P20-argo-cd / U2 (score 1): report:P20-argo-cd--testing.md — Some test fixture utilities exist but no exported test package for downstream application-set or plugin authors.
  • P20-argo-cd / U3 (score 1): report:P20-argo-cd--testing.md — Generated mock infrastructure used across repository, cluster, and application controllers; mock usage is broad within internal packages.
  • P20-argo-cd / U5 (score 2): report:P20-argo-cd--testing.md — Table-driven tests used in diff and sync engine packages.

P21-tekton-pipeline#

  • P21-tekton-pipeline / U1 (score 2): report:P21-tekton-pipeline--testing.md — Reconciler logic tested in-process with fake Kubernetes clients; E2E in test/ requires a real cluster.
  • P21-tekton-pipeline / U2 (score 1): report:P21-tekton-pipeline--testing.md — pkg/testing has some helper functions; not a full public API for downstream pipeline authors.
  • P21-tekton-pipeline / U3 (score 2): report:P21-tekton-pipeline--testing.md — Reconciler tests use fake Kubernetes API clients (not generated business-logic mocks); internal pipeline execution logic uses real implementations.
  • P21-tekton-pipeline / U5 (score 2): report:P21-tekton-pipeline--testing.md — Table-driven tests in reconciler and API packages.

P22-go#

  • P22-go / U1 (score 3): report:P22-go--testing.md — Entire Go standard library test suite runs without any external dependencies; testing/iotest, testing/fstest, and embedded fake implementations ensure complete hermetic coverage.
  • P22-go / U2 (score 3): report:P22-go--testing.md — net/http/httptest, testing/iotest, testing/fstest, go/analysis/analysistest are public versioned test helper packages in the standard library, used by downstream Go developers universally; testscript exported for tool testing.
  • P22-go / U3 (score 3): report:P22-go--testing.md — No mock frameworks. The testing/iotest, net/http/httptest implementations ARE the real test implementations. No generated mocks anywhere in the standard library.
  • P22-go / U4 (score 2): report:P22-go--testing.md — go/analysis/analysistest provides a generic test harness for all analyzers to pass; io/fs has fstest.MapFS usable as a test backend; conformance pattern for one subsystem (filesystem).
  • P22-go / U5 (score 3): report:P22-go--testing.md — testscript DSL for CLI tools; go/analysis/analysistest uses .go source files as test cases; table-driven tests pervasive throughout stdlib; multiple declarative formats.

P23-gin#

  • P23-gin / U1 (score 2): report:P23-gin--testing.md — Unit and integration tests use httptest.NewRecorder() and httptest.NewServer(); no external services required; real HTTP servers started in-process for integration tests.
  • P23-gin / U2 (score 2): report:P23-gin--testing.md — CreateTestContext() and CreateTestContextOnly() are exported production-API functions in test_helpers.go designed for downstream handler-testing use.
  • P23-gin / U3 (score 3): report:P23-gin--testing.md — No mocking framework. The OptionFunc pattern and real gin.Engine instances mean tests always use real engines; the only fake is mockWriter (a no-op io.Writer for benchmarks).
  • P23-gin / U5 (score 2): report:P23-gin--testing.md — 81 loop-over-slice table patterns; t.Run subtests in binding tests; structured route test request tables.

P24-echo#

  • P24-echo / U1 (score 2): report:P24-echo--testing.md — Tests use httptest.NewRecorder() and real echo instances; no external services required; middleware and binder tested in-process.
  • P24-echo / U2 (score 2): report:P24-echo--testing.md — Exported test helper constructors present for context and response creation; usable by downstream echo middleware authors.
  • P24-echo / U3 (score 3): report:P24-echo--testing.md — No mocking framework; tests use real echo instances and httptest; the framework’s concrete types are the test implementations.
  • P24-echo / U5 (score 2): report:P24-echo--testing.md — Table-driven tests throughout middleware and binder packages.

P25-fiber#

  • P25-fiber / U1 (score 3): report:P25-fiber--testing.md — Full test suite runs in-process using fiber’s test request method (app.Test(req)); no real TCP sockets opened; entirely in-memory request/response cycle.
  • P25-fiber / U3 (score 3): report:P25-fiber--testing.md — No mocking framework; app.Test() is a real in-process HTTP handler invocation; fiber’s concrete App and Ctx are the test implementations.
  • P25-fiber / U5 (score 2): report:P25-fiber--testing.md — Table-driven tests throughout router and middleware packages.

P26-buffalo#

  • P26-buffalo / U1 (score 2): report:P26-buffalo--testing.md — Core framework logic testable in-process; database-dependent tests require a configured database.
  • P26-buffalo / U3 (score 2): report:P26-buffalo--testing.md — Test helper functions used for request simulation; minimal mock usage.
  • P26-buffalo / U5 (score 1): report:P26-buffalo--testing.md — Some table-driven test patterns but inconsistent adoption; many individual test functions rather than consolidated subtests.

P27-beego#

  • P27-beego / U1 (score 1): report:P27-beego--testing.md — Many module tests require real databases (MySQL, PostgreSQL, Redis); unit-level coverage thin.
  • P27-beego / U2 (score 2): report:P27-beego--testing.md — beego/testing package and helper constructors exported for downstream application developers to test Beego handlers.
  • P27-beego / U3 (score 1): report:P27-beego--testing.md — Generated mock or manually constructed mock interfaces used across ORM and session layers; mocking penetrates internal boundaries.
  • P27-beego / U5 (score 2): report:P27-beego--testing.md — Table-driven tests used in router and filter packages.

P28-gorm#

  • P28-gorm / U1 (score 2): report:P28-gorm--testing.md — Core ORM logic tested in-process with SQLite; full integration tests require MySQL/PostgreSQL/SQL Server connections.
  • P28-gorm / U2 (score 1): report:P28-gorm--testing.md — Some test utilities in the test suite; not a versioned public package for GORM plugin/dialect authors.
  • P28-gorm / U3 (score 2): report:P28-gorm--testing.md — Real SQLite used for most tests; interface mocking limited to dialector and plugin boundary.
  • P28-gorm / U5 (score 2): report:P28-gorm--testing.md — Table-driven tests throughout CRUD and association packages.

P29-sqlc#

  • P29-sqlc / U1 (score 2): report:P29-sqlc--testing.md — Code generation tests run in-process; generated code integration tests require a real database backend.
  • P29-sqlc / U3 (score 3): report:P29-sqlc--testing.md — No mock framework; the code generator output IS the artifact under test; SQL queries and schema files drive all test logic without mock abstractions.
  • P29-sqlc / U5 (score 3): report:P29-sqlc--testing.md — .sql schema and query files are the declarative test case format; code generation is driven by data files; golden-file comparison for generated output; multiple file-based declarative formats.

P30-viper#

  • P30-viper / U1 (score 3): report:P30-viper--testing.md — Entire test suite runs in-process; file system access uses afero in-memory FS; no network or external services required.
  • P30-viper / U3 (score 3): report:P30-viper--testing.md — No mock framework; afero.MemMapFs IS the test implementation of the filesystem abstraction; all config sources injectable without mocking.
  • P30-viper / U5 (score 2): report:P30-viper--testing.md — Table-driven tests throughout config parsing and environment variable handling.

P31-cobra#

  • P31-cobra / U1 (score 3): report:P31-cobra--testing.md — Entire test suite runs in-process; command execution and output capture done via Go buffers; no external process spawning.
  • P31-cobra / U3 (score 3): report:P31-cobra--testing.md — No mock framework; cobra commands are concrete structs and the tests drive real command execution through the framework.
  • P31-cobra / U5 (score 2): report:P31-cobra--testing.md — Table-driven tests throughout flag parsing, completion, and usage packages.

P32-fzf#

  • P32-fzf / U1 (score 2): report:P32-fzf--testing.md — Core fuzzy-matching algorithm fully hermetic; terminal rendering tests require tty interaction; most of the value-bearing tests are pure-function tests.
  • P32-fzf / U3 (score 3): report:P32-fzf--testing.md — No mock framework; the fuzzy matching core is pure functions; tests drive real algorithm implementations with no abstraction layer.
  • P32-fzf / U5 (score 2): report:P32-fzf--testing.md — Table-driven tests for matching algorithm cases; structured input/output pairs.

P33-gh#

  • P33-gh / U1 (score 2): report:P33-gh--testing.md — GitHub API calls intercepted via httpmock; most tests run without real network; E2E scenarios require GitHub credentials.
  • P33-gh / U2 (score 1): report:P33-gh--testing.md — pkg/httpmock and pkg/iostreams/iostreams.go test helpers exist; not a full versioned public test package for extension authors.
  • P33-gh / U3 (score 2): report:P33-gh--testing.md — Real command logic; GitHub API calls mocked at the HTTP transport boundary via httpmock; internal command logic uses real implementations.
  • P33-gh / U5 (score 2): report:P33-gh--testing.md — Table-driven tests used throughout command and factory packages.

P34-gitea#

  • P34-gitea / U1 (score 1): report:P34-gitea--testing.md — Integration tests require real database (SQLite, PostgreSQL, MySQL) and optionally external services (LDAP, OAuth); unit coverage of pure logic is hermetic.
  • P34-gitea / U2 (score 1): report:P34-gitea--testing.md — modules/test package provides assertion helpers; primarily internal use.
  • P34-gitea / U3 (score 2): report:P34-gitea--testing.md — Real database used for most model tests; some mock usage at external service interfaces (LDAP, email).
  • P34-gitea / U5 (score 2): report:P34-gitea--testing.md — Table-driven tests in service and API handler packages.

P35-gogs#

  • P35-gogs / U1 (score 1): report:P35-gogs--testing.md — Tests depend on configured databases and filesystem; limited hermetic unit test infrastructure.
  • P35-gogs / U3 (score 1): report:P35-gogs--testing.md — Limited test infrastructure overall; no systematic mock strategy; some external service dependencies uncontrolled.
  • P35-gogs / U5 (score 2): report:P35-gogs--testing.md — Table-driven tests appear in utility packages; inconsistently adopted.

P36-drone#

  • P36-drone / U1 (score 1): report:P36-drone--testing.md — Database integration tests require real PostgreSQL or MySQL; many tests couple to external SCM webhooks.
  • P36-drone / U3 (score 1): report:P36-drone--testing.md — Hand-written mock stores used broadly across handler and service layers; mock usage extends to core business logic boundaries.
  • P36-drone / U5 (score 2): report:P36-drone--testing.md — Table-driven tests in webhook parsing and pipeline schedule packages.

P37-buildkite-agent#

  • P37-buildkite-agent / U1 (score 2): report:P37-buildkite-agent--testing.md — Core agent loop and job runner tested in-process using process mocking; API calls intercepted; full E2E needs real Buildkite API and agent token.
  • P37-buildkite-agent / U3 (score 2): report:P37-buildkite-agent--testing.md — API client mocked at the HTTP transport boundary; job executor and process management tested with real in-process logic.
  • P37-buildkite-agent / U5 (score 2): report:P37-buildkite-agent--testing.md — Table-driven tests in job and pipeline packages.

P38-restic#

  • P38-restic / U1 (score 2): report:P38-restic--testing.md — Core archiver and chunker tested in-process; backend tests use real local filesystem; only cloud backend tests require real external credentials.
  • P38-restic / U2 (score 1): report:P38-restic--testing.md — internal/test package provides test helpers; internal use only, not exported for downstream backup tool authors.
  • P38-restic / U3 (score 2): report:P38-restic--testing.md — Real local backend used for most tests; remote backend mocked/faked at the backend.Backend interface boundary.
  • P38-restic / U4 (score 2): report:P38-restic--testing.md — backend/test package contains a generic test suite that every backend implementation must pass (TestSuiteBackend); parameterized over local, SFTP, S3, and other backends.
  • P38-restic / U5 (score 2): report:P38-restic--testing.md — Table-driven tests throughout crypto and archiver packages.

P39-syncthing#

  • P39-syncthing / U1 (score 2): report:P39-syncthing--testing.md — Protocol and database tests run in-process; network sync tests require real OS sockets but no external services.
  • P39-syncthing / U3 (score 1): report:P39-syncthing--testing.md — Some interface mocking in the model layer; integration tests mix real and mock implementations inconsistently.
  • P39-syncthing / U5 (score 2): report:P39-syncthing--testing.md — Table-driven tests in protocol decoding and block matching packages.

P40-rclone#

  • P40-rclone / U1 (score 2): report:P40-rclone--testing.md — Core sync and copy operations testable in-process with local filesystem backend; cloud backend tests require real API credentials.
  • P40-rclone / U2 (score 1): report:P40-rclone--testing.md — fstest package provides test helper functions; used internally, not versioned for downstream cloud backend authors.
  • P40-rclone / U3 (score 2): report:P40-rclone--testing.md — Local filesystem backend used as the reference implementation for testing; cloud backends mocked or skipped without real credentials.
  • P40-rclone / U4 (score 3): report:P40-rclone--testing.md — fstest/fstestcase is a generic parameterized acceptance suite that every fs.Fs backend implementation must pass; used across all 40+ cloud providers including local, S3, GCS, SFTP; multiple subsystems covered.
  • P40-rclone / U5 (score 2): report:P40-rclone--testing.md — Table-driven tests throughout filter and operations packages.

P41-frp#

  • P41-frp / U1 (score 1): report:P41-frp--testing.md — Unit tests are in-process and hermetic; E2E suite starts real frps/frpc child processes; most behavioral coverage in process-level E2E.
  • P41-frp / U2 (score 1): report:P41-frp--testing.md — test/e2e/framework/, test/e2e/mock/server/, and test/e2e/pkg/ provide E2E infrastructure; internal to the project, not versioned for downstream tunnel library users.
  • P41-frp / U3 (score 2): report:P41-frp--testing.md — Manual interface fakes (failingConnector, fakeLn) used precisely at seam boundaries; no generated mocks; fakeLn implements net.Listener with channels.
  • P41-frp / U5 (score 2): report:P41-frp--testing.md — Table-driven tests heavy in config and serialization; pkg/config/load_test.go tests TOML/YAML/JSON in one loop.

P42-headscale#

  • P42-headscale / U1 (score 2): report:P42-headscale--testing.md — Three-tier pyramid: unit tests hermetic, servertest tier runs real Headscale + real Tailscale SDK clients via httptest.Server (in-process); Docker E2E at tier 3.
  • P42-headscale / U2 (score 1): report:P42-headscale--testing.md — hscontrol/servertest/ is a rich in-process harness (TestServer, TestHarness, TestClient, assertions.go) but is internal to the project, not exported for downstream Headscale integrators.
  • P42-headscale / U3 (score 2): report:P42-headscale--testing.md — Hand-written mockNodeConnection only at the batcher interface boundary; everything else (real Headscale server, real SQLite, real Tailscale SDK clients) uses real implementations.
  • P42-headscale / U4 (score 1): report:P42-headscale--testing.md — Golden file tests for ACL compatibility dynamically load testdata/acl_results/*.json (hundreds of files from Tailscale SaaS captures); shared assertion helpers across policy tests; no formal generic parameterized conformance suite.
  • P42-headscale / U5 (score 2): report:P42-headscale--testing.md — 553 occurrences of table-driven patterns; golden file loader (testdata/acl_results/*.json) as a data-file declarative format.

P43-tailscale#

  • P43-tailscale / U1 (score 2): report:P43-tailscale--testing.md — lapitest and testcontrol.Server run fully in-process via httptest; SSH integration tests use Docker; most layers hermetic.
  • P43-tailscale / U2 (score 1): report:P43-tailscale--testing.md — ipn/lapitest, net/stun/stuntest, appc/appctest exist as named test helper sub-packages; tstest referenced extensively; no single versioned public test package for external Tailscale SDK users.
  • P43-tailscale / U3 (score 2): report:P43-tailscale--testing.md — Consumer-side narrow interfaces with hand-written fakes; testcontrol.Server is a real protocol server implementation; lapitest wires a real LocalBackend; no mock generation framework.
  • P43-tailscale / U5 (score 2): report:P43-tailscale--testing.md — 1,076 occurrences of table-driven patterns with consistent tt/tc naming; testing/synctest for time-deterministic async tests.

P44-wireguard-go#

  • P44-wireguard-go / U1 (score 3): report:P44-wireguard-go--testing.md — ChannelBind and ChannelTUN are channel-backed in-process implementations of conn.Bind and tun.Device; end-to-end device tests (TestTwoDevicePing) run without any OS sockets; entire suite runs in-process.
  • P44-wireguard-go / U2 (score 2): report:P44-wireguard-go--testing.md — conn/bindtest (exports ChannelBind, ChannelEndpoint) and tun/tuntest (exports ChannelTUN, Ping) are public, importable test helper packages; var _ conn.Bind = (*ChannelBind)(nil) compile-time checks in place.
  • P44-wireguard-go / U3 (score 3): report:P44-wireguard-go--testing.md — No mock framework. ChannelBind and ChannelTUN are fully functional in-memory implementations (not stubs); they handle real packet flow through channels. “Real implementations are the test implementations.”
  • P44-wireguard-go / U5 (score 2): report:P44-wireguard-go--testing.md — Table-driven tests for KDF vectors and AllowedIPs cases; oracle/randomized testing (TestTrieRandom with SlowRouter) as a data-driven correctness strategy.
  • P44-wireguard-go / U6 (score 2): report:P44-wireguard-go--testing.md — Custom goroutineLeakCheck(t) using runtime/pprof registered via t.Cleanup in device tests; polls for up to 10 seconds on test exit; used in the most goroutine-heavy test package.

P45-delve#

  • P45-delve / U1 (score 1): report:P45-delve--testing.md — Most tests require real OS processes compiled from fixtures; “Every test that exercises variable evaluation starts a real OS process.” Some opcode/parsing tests are hermetic but not dominant.
  • P45-delve / U2 (score 1): report:P45-delve--testing.md — pkg/proc/test (protest) and service/dap/daptest/ exist as test support sub-packages; primarily internal use.
  • P45-delve / U3 (score 3): report:P45-delve--testing.md — “Strategy: None — Delve’s tests use no mocking whatsoever. Tests exercise the real process backend against real compiled binaries.” DAP test client speaks real protocol over net.Pipe().
  • P45-delve / U4 (score 2): report:P45-delve--testing.md — Multi-backend parameterization: the same ~400 test functions in proc_test.go and integration2_test.go run against native, lldb, and rr backends via -backend flag; backend parity enforced by a shared test corpus.
  • P45-delve / U5 (score 2): report:P45-delve--testing.md — 197 occurrences of table-driven patterns; TestVariableEvaluation covers every Go type via struct slice; server_test.go subtests parameterized over stop modes.

P46-air#

  • P46-air / U1 (score 1): report:P46-air--testing.md — Config and regex tests are hermetic; integration tests (TestRebuild) spin up real Go subprocess builds, poll TCP ports; file-watching requires real filesystem.
  • P46-air / U3 (score 2): report:P46-air--testing.md — Only the exiter interface (one-method, wraps os.Exit) is swapped in tests; “Everything else is tested through real types.” Real Engine, real filesystem, real goroutines.
  • P46-air / U5 (score 2): report:P46-air--testing.md — 39 t.Run() calls across test files; config parsing and path utility branches covered via table-driven cases.

P47-pop#

  • P47-pop / U1 (score 1): report:P47-pop--testing.md — Unit tests for pure logic run without database; integration tests require a real database (MySQL, PostgreSQL, CockroachDB, or SQLite) via GitHub Actions service containers or local configuration.
  • P47-pop / U3 (score 2): report:P47-pop--testing.md — Hand-written mockTranslator in genny/fizz/ctable/mocks_test.go for code-gen testing; all DB integration tests use real database connections; no gomock/mockery.
  • P47-pop / U4 (score 1): report:P47-pop--testing.md — Dialect-specific tests (MySQL, PostgreSQL, CockroachDB, SQLite) run the same test logic with SODA_DIALECT env var; testify/suite types exist per dialect but are thinly used; shared assertions not formalized.
  • P47-pop / U5 (score 1): report:P47-pop--testing.md — “The grep for classic testCases := []struct / tt.Run patterns returns 0 hits.” Lighter table forms appear (iterate over value slices) but standard Go subtests with t.Run are absent.

P48-pocketbase#

  • P48-pocketbase / U1 (score 3): report:P48-pocketbase--testing.md — “httptest.NewRecorder() + fully constructed router against a real in-process SQLite database with committed fixture data.” No Docker, no external services; every test gets a deep-copied SQLite snapshot in a temp directory.
  • P48-pocketbase / U2 (score 3): report:P48-pocketbase--testing.md — github.com/pocketbase/pocketbase/tests is a public package with TestApp, ApiScenario, TestMailer, MockMultipartData, TestValidationErrors — designed for and documented for downstream PocketBase application developers.
  • P48-pocketbase / U3 (score 3): report:P48-pocketbase--testing.md — “No mocks — real implementations everywhere. TestApp bootstraps an actual core.BaseApp with SQLite.” TestMailer stub injected via hook at external boundary only; everything else is real.
  • P48-pocketbase / U5 (score 3): report:P48-pocketbase--testing.md — ApiScenario struct is a full declarative DSL for HTTP tests (method, URL, body, headers, ExpectedStatus, ExpectedContent, ExpectedEvents); “144 of 180 test files contain a scenarios := []... slice”; plus standard table-driven unit tests.

P49-nats-server#

  • P49-nats-server / U1 (score 2): report:P49-nats-server--testing.md — “In-process servers bound to 127.0.0.1 with Port: -1 (OS-assigned random port). No Docker, no testcontainers, no external processes.” However, OS TCP sockets are used for in-process cluster tests — not purely in-memory.
  • P49-nats-server / U2 (score 1): report:P49-nats-server--testing.md — test/test.go (660 lines) and server/test_test.go provide test infrastructure; hand-rolled require_* assertion family; internal use only.
  • P49-nats-server / U3 (score 3): report:P49-nats-server--testing.md — “No mocking whatsoever. Tests use real in-process servers exclusively. There is no unit test isolation below the server level — no stub transports, no mock accounts.”
  • P49-nats-server / U5 (score 1): report:P49-nats-server--testing.md — “49 occurrences of table-driven patterns… most tests are single-scenario integration tests rather than table-driven unit tests” in a 3,141-test suite.

P50-temporal#

  • P50-temporal / U1 (score 2): report:P50-temporal--testing.md — OneBox in-process server enables most functional tests without Docker using SQLite; full persistence matrix (Cassandra, PostgreSQL) requires Docker Compose containers in CI.
  • P50-temporal / U2 (score 1): report:P50-temporal--testing.md — common/testing/ has 13 packages (parallelsuite, testvars, historyrequire, protorequire, etc.) but these are internal to Temporal; no public pkg/test for Temporal SDK users to test their workflows.
  • P50-temporal / U3 (score 0): report:P50-temporal--testing.md — “126 *_mock.go files exist — the highest count in the 50-project set.” Generated mocks via go.uber.org/mock/gomock cover gRPC service boundaries, persistence layer, and internal component interfaces. Pervasive mock-everything style.
  • P50-temporal / U4 (score 1): report:P50-temporal--testing.md — Multi-database persistence matrix (Cassandra, PostgreSQL, MySQL, SQLite) runs the same functional tests against multiple backends; shared but informally structured rather than a generic parameterized acceptance suite.
  • P50-temporal / U5 (score 2): report:P50-temporal--testing.md — 1,775 occurrences of table-driven patterns; historyrequire DSL for workflow history event assertions (human-readable event-type-name format).

P51-crush#

  • P51-crush / U1 (score 3): report:P51-crush--testing.md — “In-process, using real SQLite (via t.TempDir()), real service implementations, and HTTP cassette replay for the LLM backend. No Docker or testcontainers.” VCR cassette replay eliminates all live network calls.
  • P51-crush / U2 (score 1): report:P51-crush--testing.md — config.NewTestStore exported from production code for test use; fakeEnv and helpers in common_test.go; no full versioned public test package.
  • P51-crush / U3 (score 3): report:P51-crush--testing.md — Manual interface implementations only (no gomock/mockery); testEnv() constructs real session.Service, message.Service, history.Service backed by real SQLite — “Real services over fakes.”
  • P51-crush / U5 (score 2): report:P51-crush--testing.md — 376 t.Parallel() calls and 43 table-driven test occurrences; golden file tests for TUI rendering (github.com/charmbracelet/x/exp/golden); VCR cassette files as declarative recorded interactions.

Per-Trait Commentary#

U1 — Hermetic by construction#

Score distribution: 3 (textbook) — P06-hugo, P22-go, P25-fiber, P30-viper, P31-cobra, P44-wireguard-go, P48-pocketbase, P51-crush (8 projects); 2 (clear) — 26 projects; 1 (weak) — 15 projects; 0 — 2 projects.

The modal score is 2, meaning most Go projects achieve partial hermeticity: unit tests run cleanly in-process, but integration or E2E tests require real infrastructure. The projects scoring 3 share a common trait — they found a way to make the infrastructure itself hermetic. Hugo uses afero.MemMapFs to eliminate real filesystem access. Fiber provides app.Test() which bypasses TCP entirely. WireGuard-go uses ChannelBind/ChannelTUN to replace OS networking with channel-backed fakes. PocketBase uses SQLite with temp-dir fixture clones so even full API integration tests need no external database. Crush adds VCR cassette replay to remove the last non-hermetic element (LLM API calls).

The projects scoring 1 are almost entirely infrastructure-heavy systems where real-world coupling is genuinely hard to avoid: Kubernetes, Istio, ArgoCD, K3s all require a running cluster for their most important tests. Gitea, Drone, Gogs, and Buffalo require real databases at the unit tier. The projects in this group are not failing at testability engineering — they face a harder problem domain. The notable outlier is Delve (score 1), which requires real OS processes even for variable evaluation tests; this is a deliberate correctness trade-off for a debugger, not a design failure.

U2 — Exported test-helper package#

Score distribution: 3 (textbook) — P10-fyne, P22-go, P48-pocketbase (3 projects); 2 (clear) — P04-prometheus, P09-cockroach, P12-consul, P18-helm, P23-gin, P24-echo, P27-beego, P44-wireguard-go (8 projects); 1 (weak) — 26 projects; 0 — 14 projects.

This trait shows the most skewed distribution in the scorecard. Only 3 projects ship a true public versioned test helper package designed explicitly for downstream consumers: Go’s standard library (the gold standard, with net/http/httptest, testing/iotest, testing/fstest), Fyne (whose fyne.io/fyne/v2/test package lets any Fyne app author test without mocking Fyne internals), and PocketBase (whose tests.ApiScenario is used by plugin and application developers).

The 14 projects with score 0 mostly have simple enough interfaces that downstream users don’t need help testing code that depends on them (viper, cobra, fzf) or they have rich internal test infrastructure that was never extracted into a reusable public package. The score-2 cluster (consul’s sdk/testutil, gin’s CreateTestContext, helm’s chartutil, cockroach’s testutils) shows that many projects have partially crossed this threshold but haven’t committed to a fully versioned, documented public contract.

U3 — Low mock burden#

Score distribution: 3 (textbook) — P06-hugo, P10-fyne, P22-go, P23-gin, P24-echo, P25-fiber, P29-sqlc, P30-viper, P31-cobra, P32-fzf, P44-wireguard-go, P45-delve, P48-pocketbase, P49-nats-server, P51-crush (15 projects); 2 (clear) — 27 projects; 1 (weak) — P05-grafana, P12-consul, P17-k3s, P20-argo-cd, P27-beego, P35-gogs, P36-drone, P39-syncthing (8 projects); 0 — P50-temporal (1 project).

U3 is the most bimodal trait. A clear majority of projects (42 of 51) score 2 or 3. The Go ecosystem appears to have internalized “prefer real implementations over mocks” as a cultural norm. The score-3 cluster includes diverse project types: libraries (cobra, viper, fzf), frameworks (gin, echo, fiber), infrastructure tools (hugo, wireguard-go), debuggers (delve), and application servers (pocketbase, nats-server). The common thread is that these projects have narrow, replaceable abstractions at true external boundaries (filesystem, network, OS processes) and use real implementations everywhere else.

The single score-0 project (Temporal) is the outlier that proves the rule. With 126 generated mock files — the highest count in the entire dataset — Temporal has adopted a thoroughgoing mock-everything style for its distributed system components. This reflects a deliberate engineering choice for a system with complex multi-service interactions, but it comes at a cost: the test suite requires significant mock maintenance and the 3-retry flakiness policy in CI suggests some mock/reality divergence.

The score-1 cluster (Grafana, Consul, K3s, Argo-CD, Gogs, Drone, Syncthing) reflects projects where mocking has penetrated internal subsystem boundaries, making tests more brittle and harder to refactor.

U4 — Conformance / acceptance suite for replaceable parts#

Score distribution: 3 (textbook) — P09-cockroach, P40-rclone (2 projects); 2 (clear) — P03-etcd, P04-prometheus, P22-go, P38-restic, P45-delve (5 projects); 1 (weak) — P07-traefik, P42-headscale, P47-pop, P50-temporal (4 projects); 0 — 40 projects.

U4 is the rarest trait: 40 of 51 projects score 0. A conformance suite requires two preconditions that rarely coexist: (a) a well-defined interface for replaceable implementations, and (b) the disciplined work of actually writing a generic parameterized suite for it. The score-3 projects demonstrate both: CockroachDB has KV storage and SQL executor conformance tests; rclone’s fstest/fstestcase is an industry-grade example of how to parameterize a test suite over 40+ backend implementations.

The score-2 cluster shows partial adoption: Prometheus’s storage/testing suite covers storage backends; etcd’s backend tests cover the mvcc store; the Go standard library’s fstest.TestFS parameterizes over fs.FS implementations; restic’s backend/test.TestSuiteBackend runs against all backup backends; Delve’s multi-backend runner covers native/lldb/rr backends. All five have a clear system-under-test interface and a mechanism to run the same test corpus against multiple implementations.

The near-absence of this trait across 40 projects is noteworthy. Many projects expose plugin or provider interfaces (Consul providers, Terraform providers, Dapr components, Istio extensions) without a shared conformance suite — meaning each new implementation gets only ad-hoc testing rather than systematic correctness enforcement.

U5 — DSL / declarative case format#

Score distribution: 3 (textbook) — P04-prometheus, P06-hugo, P09-cockroach, P22-go, P29-sqlc, P48-pocketbase (6 projects); 2 (clear) — 43 projects; 1 (weak) — P26-buffalo, P47-pop, P49-nats-server (3 projects); 0 — 0 projects.

U5 shows the highest floor of any trait: no project scored 0. Table-driven tests are so deeply embedded in Go culture that even projects with otherwise weak testing stories use them. The modal score is 2 (43 of 51 projects).

The score-3 cluster has genuinely elevated this trait. PocketBase’s ApiScenario struct is a purpose-built DSL where adding a test case means adding a struct literal — the test infrastructure interprets it, no additional code needed. SQLc’s .sql schema and query files ARE the test case format; tests scale by adding SQL files. Hugo’s IntegrationTestBuilder DSL embeds an entire Hugo site in a Go raw string. Prometheus’s testscript integration and .rules golden files give three distinct declarative formats. CockroachDB’s logic tests load thousands of .sql test files. The Go standard library’s testscript, analysistest, and testing/fstest frameworks enable test scaling purely by data addition.

The score-1 outliers reveal where table-driven adoption has failed: Buffalo’s inconsistent single-test-function style, pop’s complete absence of t.Run subtests (confirmed by grep returning 0 hits), and NATS’s 49 table instances across 3,141 tests (a ratio that shows imperative integration tests dominate).

U6 — Goroutine-leak hygiene#

Score distribution: 3 (textbook) — P09-cockroach (1 project); 2 (clear) — P03-etcd, P04-prometheus, P44-wireguard-go (3 projects); 1 (weak) — 0 projects; 0 — 47 projects.

U6 is the most strikingly absent trait: 47 of 51 projects score 0. The overwhelming majority of Go projects in this corpus — including sophisticated distributed systems with significant goroutine concurrency — do not use goleak, leaktest, or equivalent goroutine leak detection libraries.

The four non-zero projects are instructive. CockroachDB (score 3) integrates goroutine leak checks pervasively — appropriate for a database with complex background goroutine management. Prometheus and etcd (score 2) use goleak in their most concurrency-intensive packages. WireGuard-go (score 2) uses a custom pprof-based leak checker in its device tests, demonstrating that you don’t need goleak specifically — the behavior matters more than the tool.

The absence of this trait across 47 projects is not explained by project simplicity. NATS (3,141 tests, in-process cluster testing), Temporal (741 test files, heavy goroutine use), Headscale (explicit concurrency test files), and Tailscale (testing/synctest adoption) all have sophisticated test suites but no goroutine leak hygiene. This represents a systematic blind spot: the Go testing ecosystem has internalized race detection (-race) as standard but has not yet normalized goroutine lifecycle verification as a first-class correctness property.

Confidence Note#

Scores with highest uncertainty:

  • U2 for tailscale: The tstest package tree is documented as extensive in the Phase 1 report but was not present in the analyzed clone. Its actual exported surface might warrant score 2. Scored 1 conservatively.

  • U1 for NATS-server: Scored 2 rather than 3 because cluster tests use real OS loopback TCP ports. The distinction between “in-process with OS networking” and “in-process with no external deps” is a rubric ambiguity; another reader might score 3 since no external services are required.

  • U3 for P43-tailscale: The consumer-side narrow interface pattern (defining a 10-method local interface instead of importing a 200-method concrete type) sits between 2 and 3. The testcontrol.Server and lapitest are real server implementations, but lightweight hand-written fakes also appear. Scored 2.

  • U4 for P47-pop: The multi-dialect test matrix (MySQL, PostgreSQL, CockroachDB, SQLite) approaches but does not quite reach a formal generic conformance suite — the SODA_DIALECT env variable dispatch is less structured than rclone’s or restic’s parameterized test suite type. Scored 1.

  • U6 for P44-wireguard-go: The custom goroutineLeakCheck(t) using runtime/pprof is functionally equivalent to goleak but not the named library. Scored 2 (used in most relevant device packages) rather than 0.

Projects most likely to be re-scored by another reader: P43-tailscale (U3: 2 vs 3), P49-nats-server (U1: 2 vs 3), P50-temporal (U4: 1 vs 2), P10-fyne (U1: 2 vs 3 given xvfb dependency on Linux).

Coverage completeness: All 51 projects read from their sole allowed source (–testing.md report). No architectural, patterns, interfaces, or other reports were consulted. Source-code fallback was not required — the Phase 1 testing reports were sufficiently detailed to score all traits.