Possibly misleading comment suggesting importing the extension

[alzafacon]

both example test files (sample/test/suite1/extension.test.ts, sample/test/suite2/extension.test.ts) have a comment

// You can import and use all API from the 'vscode' module
// as well as import your extension to test it
import * as vscode from 'vscode';
// import * as myExtension from '../extension';

I interpret this to mean that the activate method of the extension needs to be manually invoked. I believe this is the most natural interpretation. But that contradicts how the Extension Host starts up with the extension already.

I think what the comment is trying to say is that I can import my extension to test the supporting functions, classes, etc, I implemented and exported from the extension. Is this correct? if so, would it be reasonable to update the comment:

// as well as import your custom feature APIs from your extension for testing it

(Btw, I see the same thing in https://github.com/microsoft/vscode-extension-samples/blob/main/helloworld-test-sample/src/test/suite/extension.test.ts)

[segevfiner]

I'm not sure the tests share the same VM context with the actual extension either. That means global variables in the extension's code are not accessible to the tests which make it quite a bit harder to test. As the VS Code API is quite lacking in terms of automating stuff for testing.

[connor4312]

I'm not sure the tests share the same VM context with the actual extension either.

They do, that is the intention of the sample I think. I can update it.

[segevfiner]

Weird cause I have some global variable that I'm setting in activate, yet it is undefined in the test... Even after awaiting for activate...

[segevfiner]

OK. I think I see the problem. I'm using the webpack template and it seems to build the extension into dist while building it again along with the tests to out. VS Code is importing the bundle from dist even during tests, while the tests import from out. I want them to end up using the same code so they can share global data. Not sure how to go about reconfiguring this.

[connor4312]

Yea, that's the main challenge with #186

In one of my extensions built with esbuild, I was dealing with the same situation. Commands executed in the same extension host will return the original object (i.e. not json serialized versions) so I have a test-only command that gets the global I need in my tests. https://github.com/connor4312/nodejs-testing/blob/94d013a46a3abdf066b9ff83a65557ef2f51c1cf/src/test/util.ts#L11-L14

[segevfiner]

It looks to be enough to just override the extension entry point to out/extension.js and stub some handlebars-loader modules we have. But I'm not sure how to reasonably do that only for tests. I guess there isn't a separate main field that is only used during testing (Kinda like exports conditions, or the de-facto module and browser fields)