jest-community / vscode-jest

The optimal flow for Jest based testing in VS Code
MIT License
2.83k stars 291 forks source link

Where is the [Debug] button'config ? #409

Open Justin-Shen opened 5 years ago

Justin-Shen commented 5 years ago

Environment

  1. node -v: [8.9.2]

Actual Behavior

[fill] image


I want to debug per test by-self,when I click 【Debug】, something error , I can't find where to config this 【Debug】button ? Anybody can help me?


connectdotz commented 5 years ago

in How do I debug tests?:

The simplest use cases should be supported out-of-the-box, but at the latest when VS Code displays errors about the attribute program or runtimeExecutable not being available, you have to create your own debug configuration within launch.json...

lhrolim commented 5 years ago

Is there a way to force the config file path for this button ?

tostringtheory commented 4 years ago

I guess I'm facing the same issue as @lhrolim . While the regular test runner happily runs everything without an issue, when you click "Debug", it's not conveying the custom/specified jest.pathToConfig setting, and thus can't actually run the tests since it doesn't have the bootstrapping necessary.

I was just about to open up another issue before I found this one that seemed to enumerate my issue. Here's a repository that replicates the issue with minimal configuration/packages - https://github.com/tostringtheory/vscode-jest-debug-bug .

I've identified that it appears the issue lies in DebugConfigurationProvider.ts - it doesn't utilize the configuration option for the pathToConfig.

I'd be willing to generate a PR on this, but I guess I'd want some thought first on if the default SHOULD be for it to use the same config. I'd personally think so, but I wouldn't want to implement a change that breaks peoples current use of it because it operates differently. However, I'm not sure how many people have their jest config in a separate directory. The other option I suppose would either be a flag to indicate to pass the same config (that defaults to false), potentially also allowing a string path to a separate configuration for debug vs regular watch.

Thoughts on the best fix for this?

connectdotz commented 4 years ago

@tostringtheory we are working on a new major release 4.0 (#576), which includes improving the config setup. We want to move toward a wizard-like interface to help users set up all these configurations (pathToJest, debug config, etc) consistently at start-up.

Chances are most of the "guessing" logic in generating the config in the current code base will be refactored, so probably not too much point to change it at this point. But if you are interested in working on such a wizard, we will be looking forward to working with you! 😄

tostringtheory commented 4 years ago

@connectdotz - Thanks for the reply. I was uncertain of your response at first as I wasn't necessarily thinking this was an issue with the config, but more an issue with the DebugConfigurationProvider.ts in not supplying the already set configuration path to the command that runs. However in preparing my original reply, I was digging through the code, and started to gain the understanding that I could amend that command with a vscode-jest-tests command, and that it would be used by the Debug codelens command. I do still question whether or not sending the users' config should be part of the simplest installation - if the user set their config path, shouldn't it be used?

For others that come across this in the future trying to figure out/set configuration for the debug command, this is all I had to do to get it working (minus the research time):

        {
            "type": "node",
            "name": "vscode-jest-tests",
            "request": "launch",
            "program": "${workspaceFolder}/node_modules/jest/bin/jest",
            "args": [
                "--runInBand",
                "--config", "[your-path-to-config-relative-to-cwd]"
            ],
            "cwd": "${workspaceFolder}",
            "console": "integratedTerminal",
            "internalConsoleOptions": "neverOpen",
            "disableOptimisticBPs": true
        }

As for the wizard @connectdotz - I've definitely had my share of projects in creating wizards like that before. I'd potentially love to help on it, but work has been hectic for me lately (somehow busier since the virus), and I'd hate to be a hold-back on it. Do you have any documentation/concepts of what you want that experience to be like? Are you looking for a separate application, a cli tool, or just inbuilt use of the command palette "Jest - Walk me through configuration" that would just prompt settings from the user utilizing the command palette?

Last- I'll also be honest, even though I read the readme a few times, I didn't interpret this statement

The simplest use cases should be supported out-of-the-box, but at the latest when VS Code displays errors about the attribute program or runtimeExecutable not being available, you have to create your own debug configuration within launch.json...

...as meaning that my command would be consumed when clicking the debug codelens button, I more interpreted it as saying "if the simplest doesn't work, create your own config to run jest and use that; the debug command just won't work for you from this extension". In retrospect, it doesn't say that, but I'm wondering if the readme should be clarified with a simple example (like mine below for passing the config) with that just made explicit?

Anyways - thanks for helping with this great extension. Now that I've worked through most of the hiccups (except #587), I'm pretty happy with the setup!

connectdotz commented 4 years ago

Do you have any documentation/concepts of what you want that experience to be like?

good question, created a new issue #590 so we can start to discuss the desired user experience and moving toward materializing the idea...

connectdotz commented 4 years ago

I'd potentially love to help on it, but work has been hectic for me lately (somehow busier since the virus), and I'd hate to be a hold-back on it.

yeah life didn't seem to be less busy for the lucky us... no worry, you have already contributed with discussions like this! Sharing the solutions above with others is another big help 👍 . I look forward to continuing the discussion in #590.