tree 41cd02cac449d31b714c5d9bc3a10e9b7f5733d2
parent 8e1dadd138155988010c13c49682ac72fe64cb0b
author Hana <hyangah@gmail.com> 1604013157 -0400
committer Hyang-Ah Hana Kim <hyangah@gmail.com> 1605020800 +0000

test/gopls: change test environment setup to use single file edit

When we wrote the first gopls integration test, gopls required
vscode to open the workspace folder while vscode code does not
support dynamic workspace folder registration in test mode. As a
result, we ended up having a fixed workspace folder as a test fixture,
starting the test code instance with the folder, and copying
necessary files to the folder. There were so many moving parts
and this created race conditions and caused slow test run.

Since v0.4.x, gopls starts to support single file edit and automatically
constructs an internal workspace by walking the directory tree
around the open file. This CL utilizes this new capability.
In each suite, we start testing by starting a new gopls, opening
a single file, and waiting for the gopls to finish the initial package
loading.

This CL introduces Env.onPatternInTrace, which watches the
fake trace output channel, and emits an event when a registered
pattern is observed. This is a hack to wait for the gopls's internal
state to reach to a desirable state - ideally, we want to intercept
all the progress report messages like gopls' regression tests
once it is supported from the language client middleware.
https://github.com/microsoft/vscode-languageserver-node/issues/671

We also identified subtle issues in the existing test setup.

Issue 1: when the code for testing starts (using `vscode-test`'s
`runTests`) we pass the extension development path. It seems like
the vscode instance uses the `main` program specified in `package.json`
and activates it even without us asking. As a result, when we run
tests and call 'activate' again, multiple hover/completion providers
are registered, and vscode returns results from legacy and gopls-based
providers. For example, the completion middleware test was observing
entries from gopls, and goCompletionItemProvider that uses gocode.

We address this issue here by introducing the VSCODE_GO_IN_TEST
environment variable. If it is set, activate will return immediately.
So, tests can control when to register what, and how.

We need this setting in both `launch.json` and `runTest.ts` that's
invoked in CI (`npm run test`)

Issue 2: when the code for testing needs to call `activate`, we
got the extension instance by using `vscode.extensions.getExtension`
and called its `activate`. This was because there is no easy way
to supply sufficiently complete vscode's ExtensionContext.
It turned out, the extension instance vscode.extensions.getExtension
returns is the one built with the `main` program specified in
our `package.json` - that is the webpack'ed one in `dist/goMain.js`.
On the other hand, our debugging depends on pre-webpack versions
in `out/*`. This caused confusion and made debugging near impossible
(breakpoints we set on pre-webpack versions will not be hit because
we are running a different version of extension)!

We don't know if there is a way to teach `vscode-test` to use pre-webpack
version. Maybe this is our misconfiguration in our launch.json and
package.json. For now, we work around this issue by not calling
`activate`. Instead, in this gopls test, we call `buildLanguageClient`
directly. This required some refactoring work in goLanguageServer.ts.

Issue 3: sinon is cool, but stubbing vscode API for channel creation
is too much. While we refactor buildLanguageClient, we made changes
to let the caller supply the output channels.

Issue 4: as `vscode-test` starts the test vscode instance, it also
activates the registered snippets and it interferes with our gopls
completion middleware tests. In test, now we explicitly filter out
the snippet entries.

Issue 5: for some reason, the first entry in the completion middleware
test that expects 'Print' item, the filter text is not set. It can be
a bug, or working as intended (the first item has label === filterText).
Gopls is providing the expected entry. Workaround this issue by inspecting
the label field too.

Updates golang/vscode-go#655
Updates golang/vscode-go#832

Change-Id: Ic7088fd551329d1c8f78078ccb24a5f529eec72a
Reviewed-on: https://go-review.googlesource.com/c/vscode-go/+/266418
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: kokoro <noreply+kokoro@google.com>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Trust: Suzy Mueller <suzmue@golang.org>
Reviewed-by: Suzy Mueller <suzmue@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>