feat: switch to vs code tests

[ffMathy]

This switches to VS Code tests. Unfortunately this has to ditch Vitest in favor of Mocha, which is a requirement for this to work.

But the good thing is that this allows for real integration tests of the extension! They also run super fast, and it will make stabilizing the extension a lot easier.

See official guidance here: https://code.visualstudio.com/api/working-with-extensions/testing-extension

You'll also notice this has led to removing all mocks - they are no longer needed! 😍

[hi-ogawa]

Thanks for getting this started! I guess this PR is essentially for this?

• Add tests #249

[ffMathy]

Review comments have been solved.

[ffMathy]

@sheremet-va I fixed your review comments as well now.

[hi-ogawa]

I think these tests are not running because of describe instead of it. After replace describe with it, the tests fail with:

  1) TestRunner
       scheduleRun wrap test patterns if needed, (isWindows: false, customStartProcess: false):
     TypeError: Cannot redefine property: isWindows
        at Function.defineProperty (<anonymous>)
        at Context.<anonymous> (test/runner.test.ts:2:1709)
        at process.processImmediate (node:internal/timers:476:21)

  2) TestRunner
       "after each" hook for "scheduleRun wrap test patterns if needed, (isWindows: false, customStartProcess: false)":
     TypeError: Cannot redefine property: isWindows
        at Function.defineProperty (<anonymous>)
        at Context.<anonymous> (test/runner.test.ts:2:989)
        at process.processImmediate (node:internal/timers:476:21)

Maybe, we actually need to mock something after all?

[ffMathy]

Interesting. Although that failure doesn't seem to happen due to lack of mocking.

[hi-ogawa]

I didn't realize at that time, but I think this test's purpose was not about "running" but only about cli argument sanitization as written on the left side of the diff:

Mock runVitestWithApi, causing it to return its arguments as its output to allow us to assert their values

Probably the original author wanted to unit test code around here:

vscode/src/pure/runner.ts

Lines 62 to 96 in 85aa7ed

	async scheduleRun(
	testFile: string[] | undefined,
	testPattern: string | undefined,
	log: { info: (msg: string) => void; error: (line: string) => void } = { info: () => {}, error: console.error },
	workspaceEnv: Record<string, string> = {},
	vitestCommand: { cmd: string; args: string[] } = this.defaultVitestCommand
	? this.defaultVitestCommand
	: { cmd: 'npx', args: ['vitest'] },
	updateSnapshot = false,
	onUpdate?: (files: File[]) => void,
	customStartProcess?: (config: StartConfig) => void,
	cancellation?: CancellationToken,
	): Promise<{ testResultFiles: File[]; output: string }> {
	const command = vitestCommand.cmd
	const args = [
	...vitestCommand.args,
	...(testFile ? testFile.map(f => sanitizeFilePath(f)) : []),
	] as string[]
	if (updateSnapshot)
	args.push('--update')
	if (testPattern) {
	let argsValue = testPattern
	if (isWindows && !customStartProcess) {
	// Wrap the test pattern in quotes to ensure it is treated as a single argument
	argsValue = `"${argsValue.replace(/"/g, '\\"')}"`
	}
	args.push('-t', argsValue)
	}
	const workspacePath = sanitizeFilePath(this.workspacePath)
	const outputs: string[] = []
	const env = { ...process.env, ...workspaceEnv }
	let testResultFiles = [] as File[]

---

I guess another way to test this would be to extract it so that it's easy to unit test and I would normally prefer that, but I haven't read through the code to see if it's possible.