testing: expand integration testing with gopls enabled #655
Milestone
Comments
|
Change https://golang.org/cl/266418 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Nov 10, 2020
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. microsoft/vscode-languageserver-node#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 #655 Updates #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>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Workspace setup:
Focus on modules mode (since Go is now moving away from GOPATH)
Features: (see https://github.com/golang/tools/tree/master/gopls/internal/regtest)
The text was updated successfully, but these errors were encountered: