vscode icon indicating copy to clipboard operation
vscode copied to clipboard

infinitely running test with no answer

Open AmirHosein-Gharaati opened this issue 3 years ago • 11 comments

Describe the bug Vitest extension in linux OS, runs test infinitely and does not return any answer.

To Reproduce

  1. Installed Vitest extension
  2. Clicked on run all test

Expected behavior I expected to return test results but it keeps running.

Screenshots image

Environment

  • OS: Linux, Manjaro
  • VSCode version: 1.68.1
  • Vitest version: 0.22.1
  • Vitest plugin version: 0.2.24 Release

AmirHosein-Gharaati avatar Aug 18 '22 10:08 AmirHosein-Gharaati

Maybe duplicate of #55?

akngs avatar Aug 19 '22 23:08 akngs

can confirm.

Pnpm monorepo with nx

linux debian

CLI: Root package.json vitest: nx vitest

Project specific vitest: vitest --coverage

Cli passes all and stays in watch mode in dev

all tests from the extension loop indefinetly

Latest versions of vitest and vitest ext at the time of this comment

gipo355 avatar Aug 20 '22 22:08 gipo355

Are you sure the internal API connection is started? This may happen with wrong configuration when the --api argument doesn't attach to vitest but to another command.

Go to the Output tab of VSCode, filter it by Vitest and check where the --api argument goes.

Good output for vitest.commandLine configurations:

// Normal for single project structure  (it may start with `npx` in order to find vitest in node_modules)
vitest [file] --api [port]

// Normal for monorepo setup
// attaching `--api` to `vitest` by using `--` to end passing arguments to the previous command
[command: e.g. npm/yarn/nx etc.] -- vitest [file] --api [port]

Bad output for vitest.commandLine configurations:

// Wrongly adding unneeded `run`, would result in "Test result not found" error
vitest run [file] --api [port]

// Missing `--` before vitest, the `--api` argument goes to the command and not to vitest
[command] vitest [file] --api [port] 

Pustinyak avatar Aug 30 '22 05:08 Pustinyak

Are you sure the internal API connection is started? This may happen with wrong configuration when the --api argument doesn't attach to vitest but to another command.

Go to the Output tab of VSCode, filter it by Vitest and check where the --api argument goes.

Good output for vitest.commandLine configurations:

// Normal for single project structure  (it may start with `npx` in order to find vitest in node_modules)
vitest [file] --api [port]

// Normal for monorepo setup
// attaching `--api` to `vitest` by using `--` to end passing arguments to the previous command
[command: e.g. npm/yarn/nx etc.] -- vitest [file] --api [port]

Bad output for vitest.commandLine configurations:

// Wrongly adding unneeded `run`, would result in "Test result not found" error
vitest run [file] --api [port]

// Missing `--` before vitest, the `--api` argument goes to the command and not to vitest
[command] vitest [file] --api [port] 

In my case I'm confident this wasn't the issue, vitest would start and console.log that its listening on the designated port etc.

zachequi avatar Aug 30 '22 15:08 zachequi

@Pustinyak have you used pnpm with any of your testing? I saw your comment in #47 and saw many of the issues being had here are with package managers other than npm.

I know it shouldn't matter, but I've gotten my tests to filter properly by following your advice to change to pnpm test --; however my tests still spin and spin like the API results aren't getting published even in watch mode. image image

ColinKrist avatar Aug 30 '22 18:08 ColinKrist

I'm iterating this and the '--api' thing is definitely an issue, as it doesn't get appended at all for most of my configuration attempts. I'm using pnpm and was trying to do it in a monorepo but simplied to a non-mono repo bare bones test vite app.

What I've noticed is that the only way I can get the --api suffix on the vite commands is as follows:

pnpm test --

where in my package.json:

"scripts": {
  "test": "vitest",
}

However this get's misparsed (windows):

vitest "D:/vite-project/src/tests/tests.spec.ts" "--api" "60092"

Note the additional quotes added, and I get the infinite spinners. I can also get the infinite spinners in many other ways which also run the tests which say they pass, but the plugin doesn't seem to get the results. I do see tonnes of WS closed spam in the window though which I don't in OSX.

FWIW on my Mac I can run the plugin fine in a pnpm monorepo without even setting the command line at all, and I don't see any output with --api involved which is now making me a bit suspicious about the above stuff. In fact it has always just worked on OSX.

DanHarman avatar Aug 30 '22 21:08 DanHarman

Not sure if this is important but I notice in my pnpm workspace that the current working directory is different on osx (works) vs windows (fails):

OSX: [RUN.cwd] /Users/dan/Dev/app/web Windows: [RUN.cwd] /Users/dan/Dev/app

DanHarman avatar Aug 31 '22 10:08 DanHarman

Same issue running inside a devcontainer + workspace

I tried a whole bunch of vitest.commandLine settings including:

yarn vitest
npx vitest
yarn test:vitest
yarn test:vitest --

API seems to always start up "Start api process at port 40561"

and when adding -- I get the following warning in the Vitest output: "warning From Yarn 1.0 onwards, scripts don't require "--" for options to be forwarded. In a future version, any explicit "--" will be forwarded as-is to the scripts."

Example logs for both running vitest on the whole project and just one test

[INFO 12:45:03 PM] Vitest Workspace [Rails]: Vitest version = 0.22.1
[INFO 12:45:44 PM] Tests run start
[INFO 12:45:44 PM] [Workspace "Rails] Run tests from workspace
[INFO 12:45:44 PM] [Execute Vitest] yarn test:vitest /workspaces/rails/app/javascript/components/timeline/Timeline.spec.ts /workspaces/rails/app/javascript/PublicPlayer.spec.ts
[INFO 12:45:44 PM] Start api process at port 40561
[INFO 12:45:44 PM] [RUN] yarn test:vitest /workspaces/rails/app/javascript/components/timeline/Timeline.spec.ts /workspaces/rails/app/javascript/PublicPlayer.spec.ts
[INFO 12:45:44 PM] [RUN.cwd] /workspaces/rails
[INFO 12:45:44 PM] WS Close
...
[INFO 12:45:45 PM] WS Close
[INFO 12:45:45 PM] yarn run v1.22.19

$ yarn vitest /workspaces/rails/app/javascript/components/timeline/Timeline.spec.ts /workspaces/rails/app/javascript/PublicPlayer.spec.ts --api 40561

[INFO 12:45:45 PM] WS Close
...
[INFO 12:45:45 PM] WS Close
[INFO 12:45:45 PM] $ /workspaces/rails/node_modules/.bin/vitest /workspaces/rails/app/javascript/components/timeline/Timeline.spec.ts /workspaces/rails/app/javascript/PublicPlayer.spec.ts --api 40561

[INFO 12:45:45 PM] WS Close
...
[INFO 12:45:47 PM] WS Close
[INFO 12:45:47 PM] 

 DEV  v0.22.1 /workspaces/rails

      API started at http://localhost:40561



[INFO 12:45:47 PM] WS Close
...
[INFO 12:45:53 PM] WS Close
[INFO 12:45:53 PM] stdout | app/javascript/PublicPlayer.spec.ts > PublicPlayer > Headless > API for Recording Job > has `videoRuntime` property which returns total runtime of actions

...


 ✓ app/javascript/PublicPlayer.spec.ts  (3 tests) 191ms

stderr | unknown test

...



[INFO 12:45:53 PM] WS Close
...
[INFO 12:45:53 PM] WS Close
[INFO 12:45:53 PM]  ✓ app/javascript/components/timeline/Timeline.spec.ts  (2 tests) 100ms



Test Files  2 passed (2)

     Tests  5 passed (5)

  Start at  12:45:46

  Duration  6.64s (transform 4.71s, setup 0ms, collect 6.51s, tests 291ms)





 PASS  Waiting for file changes...

       press h to show help, press q to quit

[INFO 12:45:53 PM] WS Close
...
[INFO 12:45:58 PM] WS Close
[INFO 12:46:45 PM] Tests run start
[INFO 12:46:45 PM] [Workspace "Rails] Run tests from workspace
[INFO 12:46:45 PM] [Execute Vitest] yarn test:vitest /workspaces/rails/app/javascript/components/timeline/Timeline.spec.ts -t Timeline selects two actions
[INFO 12:46:45 PM] Start api process at port 45301
[INFO 12:46:45 PM] [RUN] yarn test:vitest /workspaces/rails/app/javascript/components/timeline/Timeline.spec.ts -t Timeline selects two actions
[INFO 12:46:45 PM] [RUN.cwd] /workspaces/rails
[INFO 12:46:45 PM] WS Close
[INFO 12:46:45 PM] WS Close
...
[INFO 12:46:46 PM] WS Close
[INFO 12:46:46 PM] yarn run v1.22.19

$ yarn vitest /workspaces/rails/app/javascript/components/timeline/Timeline.spec.ts -t 'Timeline selects two actions' --api 45301

[INFO 12:46:46 PM] WS Close
[INFO 12:46:46 PM] WS Close
[INFO 12:46:46 PM] WS Close
[INFO 12:46:46 PM] WS Close
[INFO 12:46:46 PM] $ /workspaces/rails/node_modules/.bin/vitest /workspaces/rails/app/javascript/components/timeline/Timeline.spec.ts -t 'Timeline selects two actions' --api 45301

[INFO 12:46:46 PM] WS Close
[INFO 12:46:46 PM] WS Close
...
[INFO 12:46:47 PM] WS Close
[INFO 12:46:47 PM] 

 DEV  v0.22.1 /workspaces/rails

      API started at http://localhost:45301



[INFO 12:46:48 PM] WS Close
...
[INFO 12:46:53 PM] WS Close
[INFO 12:46:54 PM]  ✓ app/javascript/components/timeline/Timeline.spec.ts  (2 tests | 1 skipped) 53ms



Test Files  1 passed (1)

     Tests  1 passed | 1 skipped (2)

  Start at  12:46:47

  Duration  6.16s (transform 4.12s, setup 0ms, collect 2.93s, tests 53ms)





 PASS  Waiting for file changes...

       press h to show help, press q to quit

[INFO 12:46:54 PM] WS Close
...
[INFO 12:46:59 PM] WS Close

I'm running vitest: 0.22.1 and extension v0.2.29

Juice10 avatar Sep 01 '22 12:09 Juice10

Happens with a fresh tauri+vite project as well

John0x avatar Sep 08 '22 15:09 John0x

Same problem here with a new project.

OS: MacOS 12.5.1 VSCode version: 1.71.0 Vitest version: 0.23.1 Vitest plugin version: 0.2.29 Preview

remi-deltombe avatar Sep 10 '22 05:09 remi-deltombe

Have the same issue as well, working in a multi-root VSCode workspace. I've tried variations of the command (npx vitest, pnpm test --, ... It's important to note that in the Vitest output I can (very quickly) see the tests execute and pass, but I then get spammed by 500 WS Close messages and the test UI is stuck at the spinner.

OS: MacOS 12.4 VSCode version: 1.71.2 Vitest version: 0.23.4 Vitest plugin version: 0.2.29 Preview

Ragura avatar Sep 22 '22 15:09 Ragura

I found out that after starting VSCode, running the tests from the "Testing" tab leads to the problem that the result is never shown and the spinners keep going.

But if I click on "Vitest" in the status bar at the bottom of the VSCode window, it starts the tests and they finish. After that it works even from the "Testing" tab. This will also recover from an already hanging test run.

OS: MacOS 13.0.1 VSCode version: 1.73.1 Vitest version: 0.25.3 Vitest plugin version: 0.2.34 Preview

pzerelles avatar Nov 24 '22 11:11 pzerelles

I found out that after starting VSCode, running the tests from the "Testing" tab leads to the problem that the result is never shown and the spinners keep going.

But if I click on "Vitest" in the status bar at the bottom of the VSCode window, it starts the tests and they finish. After that it works even from the "Testing" tab. This will also recover from an already hanging test run.

OS: MacOS 13.0.1 VSCode version: 1.73.1 Vitest version: 0.25.3 Vitest plugin version: 0.2.34 Preview

When clicking this button, I get a WS Opened message, which I do not see in the output at all before this.

Example of logs before the button click:

[INFO 10:27:33 AM] WS Close
[INFO 10:27:34 AM] RECONNECT
[INFO 10:27:34 AM] WS Close
[INFO 10:27:34 AM] RECONNECT
[INFO 10:27:34 AM] WS Close
[INFO 10:27:34 AM] RECONNECT
[INFO 10:27:34 AM] WS Close
[INFO 10:27:34 AM] RECONNECT
[INFO 10:27:34 AM] WS Close
[INFO 10:27:34 AM] RECONNECT
[INFO 10:27:34 AM] WS Close
[INFO 10:27:34 AM] RECONNECT
[INFO 10:27:34 AM] WS Close
[INFO 10:27:34 AM] RECONNECT
[INFO 10:27:34 AM] WS Close
[INFO 10:27:34 AM] RECONNECT
[INFO 10:27:34 AM] WS Close
[INFO 10:27:34 AM] RECONNECT
[INFO 10:27:34 AM] WS Close
[INFO 10:27:35 AM] 

 DEV  v0.25.4 <code location>

      API started at http://127.0.0.1:61817

Jernik avatar Dec 06 '22 16:12 Jernik

Same problem here:

  • running tests inside devcontainer: not working
  • running the same project locally: working

polmabri avatar Dec 18 '22 18:12 polmabri

Same problem here:

  • OS: Ubuntu 22.94
  • VSCode version: 1.71.2
  • Vitest version: 0.26.3
  • Vite version: 3.1.8

npriebe avatar Jan 09 '23 12:01 npriebe

Close as #113 merged

zxch3n avatar Feb 08 '23 13:02 zxch3n

I got rid of the spinner by installing jsdom, which was required for tests. It was indicated when I ran vitest in the console.

MentalGear avatar Feb 22 '23 10:02 MentalGear

For me it was because vitest in vscode could reslove my custom set in my tsconfig.json, the CLI yarn test worked fine but vscode sidebar did not.

Oddly vitest doesnt offer any kind of hint that this was the issue.

...
resolve: {
    alias: {
      '@utils': resolve(__dirname, './src/utils'),
      '@test': resolve(__dirname, './test'),
      '@src': resolve(__dirname, './src'),
    },
  },
...

To match my tconfig

...
"paths": {
      "@test/*": ["../test/*"],
      "@utils/*": ["./utils/*"],
      "@src/*": ["./*"]
    }
...

jswhisperer avatar Dec 01 '23 14:12 jswhisperer

I have a similar issue, if I copy everything from vite.config.ts to vitest.config.ts and replace import { defineConfig } from "vite"; with import { defineConfig } from "vitest/config"; it starts working.

FYI I'm using alias-hq to reduce duplication:

import hq from "alias-hq";
...
export default defineConfig({
  resolve: {
    // custom aliases, @components, @assets, etc.
    alias: [...hq.get("rollup", { format: "array" })],
  },

For me it was because vitest in vscode could reslove my custom set in my tsconfig.json, the CLI yarn test worked fine but vscode sidebar did not.

Oddly vitest doesnt offer any kind of hint that this was the issue.

...
resolve: {
    alias: {
      '@utils': resolve(__dirname, './src/utils'),
      '@test': resolve(__dirname, './test'),
      '@src': resolve(__dirname, './src'),
    },
  },
...

To match my tconfig

...
"paths": {
      "@test/*": ["../test/*"],
      "@utils/*": ["./utils/*"],
      "@src/*": ["./*"]
    }
...

Juice10 avatar Feb 19 '24 16:02 Juice10