Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vscode 1.32.1 jest debug cannot find test files specified if running from current file #70050

Closed
sativ01 opened this issue Mar 8, 2019 · 11 comments
Assignees
Labels
*as-designed Described behavior is as designed debug Debug viewlet, configurations, breakpoints, adapter issues

Comments

@sativ01
Copy link

sativ01 commented Mar 8, 2019

  • VSCode Version: 1.32.1
  • OS Version: Win 7

Steps to Reproduce:

  1. launch config file:
{
      "type": "node",
      "request": "launch",
      "name": "Jest Current File",
      "program": "${workspaceFolder}/node_modules/.bin/jest",
      "args": [
        "${relativeFile}",
        "--config",
        "${workspaceFolder}/tests/jest.config.js"
      ],
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen",
      "disableOptimisticBPs": true,
      "windows": {
        "program": "${workspaceFolder}/node_modules/jest/bin/jest",
      }
    }
  1. Open file that you want to test, e.g. Component.spec.jsx and run the above launch configuration
  2. Output:
Debugger listening on ws://127.0.0.1:21033/...
For help see https://nodejs.org/en/docs/inspector
Debugger attached.
No tests found, exiting with code 1
Run with `--passWithNoTests` to exit with code 0
In C:\nextgen\ng\ui\common.ui
  171 files checked.
  testMatch: C:/nextgen/ng/ui/common.ui/utils/**/*.spec.(es6|jsx),C:/nextgen/ng/ui/common.ui/components/**/*.spec.(es6|jsx) - 33 matches
  testPathIgnorePatterns: \\node_modules\\ - 171 matches
  testRegex:  - 171 matches
Pattern: components\form\__tests__\DateTimePicker.spec.jsx - 0 matches
Waiting for the debugger to disconnect...

Does this issue occur when all extensions are disabled?: Yes

It works fine with previous version of VS Code

@vscodebot
Copy link

vscodebot bot commented Mar 8, 2019

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

@vscodebot vscodebot bot added the new release label Mar 8, 2019
@weinand weinand added the debug Debug viewlet, configurations, breakpoints, adapter issues label Mar 11, 2019
@sla89
Copy link

sla89 commented Mar 11, 2019

I have the same issue.

@weinand
Copy link
Contributor

weinand commented Mar 11, 2019

Does it work with the latest Insiders?

@weinand weinand added the info-needed Issue requires more information from poster label Mar 11, 2019
@bcanseco
Copy link

bcanseco commented Mar 11, 2019

Can confirm this is happening on a fresh install of latest Insiders using jest@24.1.0.

image

$ G:\repro  cd 'g:\repro'; & 'C:\Program Files\nodejs\node.exe' '--inspect-brk=11706' 'node_modules\jest\bin\jest.js' 'src\services\jwt\index.spec.js'
Debugger listening on ws://127.0.0.1:11706/1758821f-a2fa-4350-8e4e-22e1abf0d8f9
For help see https://nodejs.org/en/docs/inspector
Debugger attached.
No tests found, exiting with code 1
Run with `--passWithNoTests` to exit with code 0
In G:\repro
  192 files checked.
  testMatch: **/__tests__/**/*.[jt]s?(x),**/?(*.)+(spec|test).[tj]s?(x) - 6 matches
  testPathIgnorePatterns: node_modules,.cache - 110 matches
  testRegex:  - 192 matches
Pattern: src\services\jwt\index.spec.js - 0 matches
Waiting for the debugger to disconnect...

@phil-scott-78
Copy link

Seeing the same thing. Looks like this is a regression of #40256 with ${relativeFile} using windows style slashes. That's why jest can't find the file. I haven't been using jest that long but it does seem like they also introduced a new parsing for testMatch that is less forgiving in a recent version per this issue jestjs/jest#7914. So maybe this regression wasn't caught until this update with jest.

@weinand weinand assigned isidorn and unassigned weinand Mar 12, 2019
@weinand weinand removed the info-needed Issue requires more information from poster label Mar 12, 2019
@isidorn
Copy link
Contributor

isidorn commented Mar 12, 2019

I confirm that there seems to be a breakage with ${relativeFile} to use win specific slashes on windows.
This is a regression.
My win VM is dog slow for some reason and I did not make any changes in this area. @alexr00 could you maybe investigate a bit, you also know the configurationResolverService?
@aeschli did you change something in this area with your path refactorings?

code pointer https://github.com/Microsoft/vscode/blob/04dbcafd35fd8de4ed4bd66022c0bba67a10dac7/src/vs/workbench/services/configurationResolver/common/variableResolver.ts#L175

@isidorn
Copy link
Contributor

isidorn commented Mar 12, 2019

After investigating with @alexr00 and @weinand we do confirm that the ${relativeFile} behavior has changed in vscode.
Now ${relativeFile} is consistent with all other predefined variables in that it returns platform specific separators. Forward slash on mac and linux and backslash on windows.
@phil-scott-78 thanks for digging out #40256 which basically contains this discussion.

${relativeFile} should behave like all other variables and due to that I am closing this as designed.

Please file this bug against Jest that it should hande backslashes on windows.

As a workaround instead of using ${relativeFile} I suggest to type in the path up to the filename. So a/b/c.txt, instead of using ${relativeFIle} use a/b/${fileBasename}. That way the arg will be based on the currently opened file.

We should have announced this change in the release notes and we appologise that we did not.

@pbricout
Copy link

pbricout commented Mar 23, 2019

@isidorn In my case I can't your proposed solution of hardcoding the path, because the path can change based on the selected file.
I use bash in my scripts and on Windows I now receive abcfile instead a/b/c/file.
The tasks.json and script is shared for both Windows and Linux platform.
What solution do you propose to handle this kind of situation?
If I could at least receive a string like a\b\c\file I could handle it in the script, but when I receive abcfile there is nothing I can do.
This topic has been discussed in the many issues already. I would be keen to find a solution could work what the shell or command is specified in the task.json or other places where these variables are used.
A parameter somewhere? It has been suggested in the some issues to have something generic in the variable ${variable:something}.
Thanks
This is following this issue I created:
#70926

@pbricout
Copy link

pbricout commented Mar 24, 2019

@isidorn I finally found a clean solution to this problem. I agree that the path format for the variables should be consistent and inline with the platform.
My problem, on Windows, was that when using something like ${relativeFile} as an argument in a task with something like that:

{
    "label": "Task",
    "type": "shell",
    "command": "myScript",
    "args": [
        "${relativeFile}"
    ]
}

the backslashes were interpreted as escape characters rather being part of the string, the script was seeing the argument $1 as abc rather than a\b\c.
To prevent this from happening, the variable need to be between quotes when passed as an argument, i.e. in the task file:

{
    "label": "Task",
    "type": "shell",
    "command": "myScript",
    "args": [
        "\"${relativeFile}\""
    ]
}

Then in my script when I receive the parameters I can transform all the back slashes in forward slashes with a variable replacement, something like in bash:

relativeFile=${1//\\/\/}"

So far this seems to work nicely and my make tasks.json and scripts compatible for both Windows and Unix platforms.

@fxlemire
Copy link

${relativeFile} should behave like all other variables and due to that I am closing this as designed.

This however breaks the WSL use case. Is there a way, when useWSL: true, to specify using forward slashes?

@fxlemire
Copy link

I forgot to add my workaround for anyone who needs it.

Basically, replace ${relativeFile} with your relative constant test path, and then add an input so you can type in the desired dynamic path.

For example, if all of your test files are under src/test:

{
  configurations: [
    {
      // ... test launch config
      "args": [
        // ... desired args
       "src/test/${input:testPath}" // instead of "${relativeFile}"
      ]
    }
  ],
  "inputs": [
    {
      "id": "testPath",
      "description": "Please enter a test path",
      "default": "", // wish we could add ${fileBasename} here but seems like it's impossible
      "type": "promptString"
    }
  ]
}

But I do hope this can stay as a workaround, and that useWSL or some other config will allow to force the path to be with forward slashes 🙏

@vscodebot vscodebot bot locked and limited conversation to collaborators Apr 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
*as-designed Described behavior is as designed debug Debug viewlet, configurations, breakpoints, adapter issues
Projects
None yet
Development

No branches or pull requests

9 participants