Using the deno vscode extension works fine for running tests, but there doesn't seem to be an option to debug a test.

Note that I can debug deno code in vscode no problem. It's the debugging tests that's the problem.

CodePudding user response：

I'll provide some steps and some example files to help you reproduce success.

Before getting started, here are the relevant manual pages which are required reading:

• 

  2. Without a .vscode/launch.json file in your workspace, you'll see the default start view:

  

  3. Select the text link "create a launch.json file". You will be presented with a list of debugger template providers:

  

  4. Select the option "Deno" and VS Code will generate a launch config file for you with default options. Below I include the version of my config that I've modified, along with comments about which values were modified and why:

  .vscode/launch.json:

  {
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
      {
        "request": "launch",
  
        /* modified: descriptive name */
        "name": "Debug tests",
  
        /* modified: was generated as "pwa-node", but VS Code shows me
        a diagnostic warning for that value: "Please use type node instead(2)" */
        "type": "node",
  
        /* disabled specific entrypoint */
        // "program": "${workspaceFolder}/main.ts",
  
        "cwd": "${workspaceFolder}",
  
        /* modified: using deno process name from my PATH */
        "runtimeExecutable": "deno",
  
        "runtimeArgs": [
          /* modified: was generated as "run", but you asked about testing */
          "test",
  
          /* modified: was generated as "--inspect", but using this option
          causes an initial break to wait for the debugger to attach */
          "--inspect-brk"
  
          /* disabled: allowing all permissions is unsafe: only allow
          the specific permissions that your scripts need */
          // "--allow-all"
        ],
        "attachSimplePort": 9229
      }
    ]
  }
  
  

  That alone should allow you to debug the tests in your workspace which don't need specific

  Note that I've also added a breakpoint to line 25 in the test.ts module so that you can inspect the test program state in that module before the assertStrictEquals statement, in order to visually confirm that the assertion should succeed before it is executed.

  Clicking the green triangle icon by the configuration name "Debug tests" begins the debug session and starts the Deno test runner. The test runner stops at an initial breakpoint (because the argument --inspect-brk was used) and waits for the debugger to attach — after a short duration, the debugger attaches, and we see the initial breakpoint:

  

  We see that the breakpoint is on the first line of a module called colors.ts — the reason why this is the initial breakpoint is that it's the first line of execution in the module graph. In the local test.ts module, the first import is from

  From here, you can use the debugger as you normally would — we see variables, call stack, etc.

  We can see the state of the variables in the first loop iteration before the call to assertStrictEquals and visually verify that the invocation should succeed:

  {
    "Local": {
      "actual": "The Last Jedi",
      "this": undefined
    },
    "Block": {
      "expected": "The Last Jedi",
      "input": "the last jedi"
    }
  }
  

  Continuing execution breaks again at the next loop iteration and we see new variables:

  {
    "Local": {
      "actual": "My Old-Fashioned Grandparents",
      "this": undefined
    },
    "Block": {
      "expected": "My Old-Fashioned Grandparents",
      "input": "my oLd-fAShiOned graNdPAreNTs"
    }
  }
  

  One final time shows the last test data case variables:

  {
    "Local": {
      "actual": "Html   Css   Js",
      "this": undefined
    },
    "Block": {
      "expected": "Html   Css   Js",
      "input": "HTML   CSS   JS"
    }
  }
  

  Clicking continue at this point finishes execution of the test runner because that was the only breakpoint and it was also the final loop iteration. The debugger detaches after the test runner finishes and the window is back to the state it was in before starting:

  

  ---

  For those interested, the ID of the VS Code theme in use in the screenshots above is hedinne.popping-and-locking-vscode and the font is Fira Code.