Support for writing tests in directly in Go.

[damnhandy]

Feature Description

I was really excited by K6 due to the fact that it's one of the few test platforms that actually allow me to define my tests in code rather than YAML or XML. While being able to write scripts in ES6 seemed cool at first, it's become a bit of a disappointment for the following reasons:

• K6 Modules do work, and to a certain degree allow you use existing NPM modules to get work done. The caveat is being aware of the fact that some NPM modules have either dependencies on Node or browser capabilities that are not present in the K6 runtime.
• Bundling adds a build step in order to bundle everything together.
• Core-JS is still missing a lot of functionality

Suggested Solution (optional)

Why not consider allowing tests to be written directly in Go? This still requires a build steps just as bundling would, but also permits users to take full advantage of the Go ecosystem rather than a watered down version of ES6.

I would image this would follow a similar model as K6 Modules where one would still define a default function and pre-compile the code. Yes, it's another runtime model to support, but one that is less limiting than building ES6 modules or creating a plugin model for K6.

[na--]

Something like this has been requested before in #751, but unfortunately, all of the technical and security challenges I described in #751 (comment) still apply. We're not ruling out support for non-JS languages in the future, and I personally would like that very much, it's just going to take a while and we have a lot of other things that have a higher priority right now 😞 We're slowly but consistently inching towards separating the load-generation and orchestration parts of k6 from the JS API, so in a sense we're slowly making the adoption of non-JS languages easier, but it's a long way of from happening...

Something that might be more immediately useful to you is the planned plugin API for k6, thanks to @andremedeiros. We plan to merge it fairly soon, probably right after #1007 (which is our current top priority). It will allow you to write arbitrary k6 plugins in Go, though you'd still have to invoke them via JS code. And there would be other drawbacks, like no cloud support or API stability guarantees between k6 releases, at least initially. But, if I understand your needs correctly, it should be good enough for most things, right?

[na--]

Forgot to link the plugin issue and PR: #1353, #1396

[damnhandy]

Thanks for the info @na-- , that makes things more clear. Personally, I'd be happier with built-in Javascript Object Signing and Encryption exposed to the JS api as I noted in #1017, but that seems a way's off for now. Will be watching this project more for updates.

[na--]

Closing this, since we merged #1688 to support the current WIP xk6 approach for Go plugins, and Go "scripting" is better covered in #751