x/tools/gopls: support renaming a test package to make it external

[mvdan]

What did you do?

Using gopls to develop Go tests. Working on a test package foo, I need to make it an external package foo_test, as otherwise I start running into import cycles when adding some more imports.

What did you expect to see?

Gopls should support renaming the package name in a test file from foo to foo_test via its rename action. It would effectively do the same that I now do manually, which is:

1. rename the package name from foo to foo_test
2. add an import of the original foo package
3. rewrite all unqualified references to the original foo package, such as Bar and Bar.Baz, to foo.Bar and foo.Bar.Baz.

Note that this process could fail if one of the unqualified references was unexported like bar, since that can't be reached via an import. I think it's fine for gopls to leave the broken foo.bar in this case, and let the user deal with the problem with the best solution - which might be to export the name, or to use an export_test.go file, or use existing exported API instead. But gopls should still aim to do as much as possible here, even if the result still has a few build errors.

What did you see instead?

protocol error: ServerError(0): cannot rename to _test package

Build info

golang.org/x/tools/gopls v0.0.0-20240823192219-0734f6249fc1
    golang.org/x/tools/gopls@v0.0.0-20240823192219-0734f6249fc1 h1:adMOkkhp86ogfEmvcqIVEfqTJiF3ZRVQc2kJRHxuv/o=
    github.com/BurntSushi/toml@v1.2.1 h1:9F2/+DoOYIOksmaJFPw1tGFy1eDnIJXg+UHjuD8lTak=
    github.com/google/go-cmp@v0.6.0 h1:ofyhxvXcZhMsU5ulbFiLKl/XBFqE1GSq7atu8tAmTRI=
    golang.org/x/exp/typeparams@v0.0.0-20221212164502-fae10dda9338 h1:2O2DON6y3XMJiQRAS1UWU+54aec2uopH3x7MAiqGW6Y=
    golang.org/x/mod@v0.20.0 h1:utOm6MM3R3dnawAiJgn0y+xvuYRsm1RKM/4giyfDgV0=
    golang.org/x/sync@v0.8.0 h1:3NFvSEYkUoMifnESzZl15y791HH1qU2xm6eCJU5ZPXQ=
    golang.org/x/telemetry@v0.0.0-20240712210958-268b4a8ec2d7 h1:nU8/tAV/21mkPrCjACUeSibjhynTovgRMXc32+Y1Aec=
    golang.org/x/text@v0.17.0 h1:XtiM5bkSOt+ewxlOE/aE/AKEHibwj/6gvWMl9Rsh0Qc=
    golang.org/x/tools@v0.24.1-0.20240823192219-0734f6249fc1 h1:KqzLXpTyjOPebElwYOBIjaAiN+nsMpzGF5V+sXq6xwQ=
    golang.org/x/vuln@v1.0.4 h1:SP0mPeg2PmGCu03V+61EcQiOjmpri2XijexKdzv8Z1I=
    honnef.co/go/tools@v0.4.7 h1:9MDAWxMoSnB6QoSqiVr7P5mtkT9pOc1kSxchzPCnqJs=
    mvdan.cc/gofumpt@v0.6.0 h1:G3QvahNDmpD+Aek/bNOLrFR2XC6ZAdo62dZu65gmwGo=
    mvdan.cc/xurls/v2@v2.5.0 h1:lyBNOm8Wo71UknhUs4QTFUNNMyxy2JEIaKKo0RWOh+8=
go: devel go1.24-36b45bca66 2024-08-26 22:29:43 +0000

[mvdan]

Note that I'm less interested in renaming from foo_test to foo, because I almost never need to do this. In contrast, I encounter "internal" test packages all the time, which I want to make external either to work around import cycles or simply to ensure that they are testing the exposed API without unnecessarily reaching for internal details.

[gabyhelp]

Related Issues and Documentation

• x/tools/gopls/internal/regtest/misc: TestRenamePackage failures #56194 (closed)
• x/tools/gopls: renaming a test results in diagnostic error from test main #36312 (closed)
• x/tools/gopls/internal/regtest/misc: TestRenamePackageWithConflicts failures #56040 (closed)
• x/tools/gopls/internal/regtest/misc: TestRenamePackageWithNonBlankSameImportPaths failures #56198 (closed)
• x/tools/gopls/internal/regtest/misc: TestRenameWithTestPackage failures #56193 (closed)
• x/tools/gopls/internal/test/integration/misc: TestRenamePackage_InternalPackage failures #66727 (closed)
• x/tools/gopls/internal/regtest/misc: rename failures #56039 (closed)
• x/tools/gopls: renaming test file package declaration `package_test `-> `package` falsely claims import cycle #45317 (closed)
• x/tools/gopls: organizeImports does not find package after changing its name #67973
• x/tools/gopls/internal/test/integration/misc: TestRenamePackage_IntermediateTestVariant failures #65853 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[findleyr]

Thanks. We should consider this as we work on other types of movement refactoring.

[adonovan]

@h9jiang This might be a good follow-up to your current work on a code action for test generation.