How to debug k6 testing script in Visual Studio Code?

OSS Support
#1

When trying to launch Visual Studio Code in debugging mode, to inspect a k6 testing script, I get the following message:

Uncaught Error: Cannot find module ‘k6’.

I’m writing the test scripts in TypeScript and I’m using NodeJS + Webpack + Babel. The .js file I pass to k6 is the bundle file created by Webpack.

My launch.json file looks like this:

“version”: “0.2.0”,
“configurations”: [
{
“name”: “Launch Program”,
“type”: “node”,
“request”: “launch”,
“cwd”: “{workspaceFolder}", "protocol": "inspector", "preLaunchTask": "npm: build", "program": "{workspaceFolder}/src/Main.ts”,
“outFiles”: [
“${workspaceFolder}/dist/Main.js”
],
“sourceMaps”: true
}
]

I’ve also added this to the tsconfig.json:

“sourceMap”: true

There is this import in my script:

import { Options } from ‘k6/options’;

Please, can anyone help? How can I configure it so that I can debug k6 testing scripts in Visual Studio Code?

#2

Hi @calderano,

I am afraid this is not possible :frowning: .

k6 is not nodejs based and also has no debugger of its own. So there is no way for visual studio code to debug k6 scripts. The error you see is because it tries to run it in nodejs and “k6” is not a module nodejs recognises.

Some thoughts on this:

  • k6 can get a debugger … I have no idea what this will entail, but it will probably be a lot of work and is likely to not be compatible with anything else, which will practically negate the majority of the benefits
  • we can reimplement the k6 modules for nodejs so you can debug them. There have been people who wanted to use their (request making) nodejs code to be run in k6, but if they use these modules in nodejs … it will also work in k6. The implementation won’t be exactly the same so there will be subtle differences which means that if you are debugging something complex you might get different behaviour. Also this will be a lot of work.

Are you doing something complex enough that console.log won’t help you? As this is the only "debugger’ currently and given my reasoning above, it is unlikely to change … soon :frowning: .

#3

Hi @mstoykov,

I was afraid of that but I was hoping there would be a way around it.
I understand. Thank you very much for the explanation.
We have just started a project using k6 and I was doing a ‘research task about it’. I believe console.log will help us.

Thank you once again!

#4

I found it helpful to run k6 via HTTP proxy such as https://mitmproxy.org/. Also if you need to debug your own code and you factor it into a separate module, then you can use the usual node debugger tools.

1 Like
#5

is likely to not be compatible with anything else, which will practically negate the majority of the benefits

I think that integration of such a debugger with the IDE could be done with the comparable efforts.
Anyway, having a debugger for a tool with scripting capabilities is a big advantage for this tool.

1 Like
#6

we can reimplement the k6 modules for nodejs so you can debug them.

That sounds like a good and straight forward solution to the problem. Is there a technical reason (e.g. performance) for the built-in modules not written in JS at the first place? Is it realistic to expect mirroring functionality to be implemented as an NPM module and supported alongside with the main product?

#7

No, or at least the k6 core dev team doesn’t plan to do it. It’s quite the significant amount of work, and even if it’s done once, having to maintain 2 separate implementations of the same API will have huge ongoing maintenance costs.

The reasons the k6 core is written in Go are many, but the standard Go HTTP library and better multi-core performance are two big ones. Every VU in k6 is a separate and (mostly) independent JavaScript runtime.

#8

Thanks for the prompt response! I didn’t mean to reimplement whole core and functionality in NodeJS instead or alongside Go implementation, you guys did a great job explaining the reasoning for using Go instead of NodeJS in the documentation. I apologize for not being clear.

What I mean was to keep core in Go, and either to reimplement the built-in module only in JS, or to have the built-in module JS implementation alongside with the implementation within the core. The JS implementation could be as simple as possible, even dummy stubs with the compatible signatures would be a great step froward (according to https://k6.io/docs/javascript-api it could be just few tens of simple functions).

That would let run a single VU in NodeJS to run the script using the NodeJS debugger. Actual load runs would still be via k6 core written in Go.