cc @bcmills @matloob

I agree that this is a bug. However, it seems like a low priority to fix, since basically nobody should have a package named pkg_test in the first place.

(But I do like to test these sorts of edge-cases just for completeness — and thanks for documenting this one!)

It may be relevant here that it's possible to have a "test-only" package: one that has tests but no code. In that case, the package name can only inferred from package tests. Consider:

-- go.mod --
module example.com

go 1.16
-- a_test.go --
package pkg

import "testing"

func TestFoo(t *testing.T) {}

In this case, tests work and the package name is considered to be "pkg":

$ go test -v
=== RUN   TestFoo
--- PASS: TestFoo (0.00s)
PASS
ok  	example.com	0.087s
$ go list -f '{{.Name}}' 
pkg

If a_test.go is modified as follows:

-package pkg
+package pkg_test

That could be interpreted to mean "make the package name pkg_test" or "make this an external test file". It seems cmd/go picks the latter at this time:

$ go test -v            
=== RUN   TestFoo
--- PASS: TestFoo (0.00s)
PASS
ok  	example.com	0.268s
$ go list -f '{{.Name}}'
pkg

It's an example demonstrating a rare edge-case where it's not possible to specify a package name and whether the test is internal or external without ambiguity as long as normal package names with a "_test" suffix are allowed to exist.

(This might be quite irrelevant since the whether a test file is internal or external isn't very meaningful for a package that has only tests but no code.)

@dmitshur, that's another neat edge-case!

I agree that it probably doesn't make much difference which direction we bias in that case, since AFAICT nothing else can import the test-only package. (Or, we could perhaps make some sort of heuristic decision about the likely package name based on the import path.)

another neat edge-case 😺：

-- pkg.go --
package pkg_test

-- pkg_test.go --
package pkg_test_test

It's result is :

PASS
ok

@bcmills I have tried to understand the thread. Tried to reproduce in my local based on the steps outlined by yunnian. Can I take this up?
Did some code deep dive. Is the go test command code the target place for understanding this better?
PS : This is my first interaction with this project.

@bcmills any followup on the above comment?

Change https://golang.org/cl/365534 mentions this issue: cmd/go: allow a package that ends with _test having an internal test package