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
createA
createB
createC
createD
do some testing with Service X
clean up
removeD
removeC
removeB
removeA
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?
