A question about polyrepo and k6 test packages

At Extend, we are beginning to build k6 suites. Think of Extend as AppleCare for anything sold online. We have 5 React front ends, 30+ Node services as AWS lambdas.

We are moving from monorepo to polyrepo, where each service is has its own repository.

We want to have a unique k6 suite per service, running in that repo.
We wish to avoid putting k6 tests for all services in a separate repo, because shift-right is not great.

The challenge is that our domain entities depend on each other. For example to create D, we have to create A, B, C;
A → B → C → D

That means each service that uses A, B, C, D will have to duplicate create + delete for ABCD; at least 8 duplications of k6 calls in this example, +1 for getting a token.

We thought of creating test-plugins, as we did for Cypress. Basically all cypress calls pertaining to package A is in a test plugin A. A service that needs the calls just installs test-plugins A, B, C, D, then they can use those calls in their test

Ex: Service X


do some testing with Service X

clean up

Here’s the question. Knowing that k6 isn’t written in node, can we use a test package approach so that we do not duplicate the k6 calls between our service repositotries?

We’re not writing any k6 plugins, just k6 test functions that CRUD entities in our domain. At the end it’s a JS script. You can import it from the next folder, or a package which is “the next folder in the node_modules”.

Any thoughts if this is a possibility?

Hi @Murat,

Currently, these are the ways you can import a k6 test function (a JS file):

  1. From a local filesystem
  2. From a remote url that can be accessed over HTTP.

It’s not possible at the moment to publish the scripts as an NPM package for example.

Here is a way it can work.
The key is to import directly from the node_modules folder.
Obviously, we have to add a npm/yarn install to our CI before running the k6 tests.

I will work on a open source repo so we can communicate and discuss improvements to the approach. So far, so good.