Is using class based approach in Grafana K6 test scripts a bad practice?

Grafana k6
1

I’m working on performance testing with Grafana K6 and trying to structure my test scripts to avoid redundancy. So I’ve implemented a class-based approach. Here’s a sample code:

const metrics = new MetricsBuilder();

const k6Runner = new K6Runner();

export const setup = () => k6Runner.doSetup();
export const options = k6Runner.getOptions();
export default () => k6Runner.run();

The MetricsBuilder class is designed to hold various metrics (including custom ones) and make them reusable across multiple test scripts. I want to keep the codebase clean, as there will be multiple test scripts and need to avoid redundancy.

However, I have a few concerns:

# Init Context and SharedArray Behavior

According to the documentation, the init context runs once per Virtual User (VU), while a SharedArray is only initialized once and shared across all VUs. I’ve noticed that the MetricsBuilder class gets initialized for every VU in the init context, but I don’t see any significant difference in the reports. Does K6 handle it appropriately?

# Is it a bad practice to use a class like MetricsBuilder in this context?

Does initializing the same object multiple times in the init context (one per VU) have any negative impact on performance or results?

# Initialization of Classes in the Init Context

I’ve noticed that initializing a class like K6Runner in the init context (e.g., const k6Runner = new K6Runner();) results in the same number of instances being created as the number of VUs.

# Is this approach considered a bad practice?

Would this lead to any issues, such as resource overuse or unexpected side effects?

# Constructor Approach with SharedArray

If we pass multiple datasets from different SharedArray instances to a constructor in the K6Runner, are there any known issues or limitations? I haven’t encountered any problems so far, but I want to ensure this is a safe practice in K6.

# Best Practices for Class-Based K6 Scripts

Are there any best practices for using a class-based approach in K6 scripts for managing metrics and modularizing test execution logic?

I would appreciate any insights or recommendations for structuring large-scale k6 test scripts to avoid redundancy while maintaining performance and accuracy. Thanks in advance.

3

Hi @techie-jay, welcome to the community forum :tada: !

Every VU is a separate JS VM. So init context needs to be executed in order to make all of the initialization for each VU. This means that whether you have classes, functions, variables - all of those need to be initialized.

I would expect making a class, initializing it and then using it, will be heavier than having functions + global variables (from my understanding you will have 1 class instance either way). But I would expect that this will be negligible compared to what is needed to run the test. So I wouldn’t take this into consideration at all.

but I don’t see any significant difference in the reports. Does K6 handle it appropriately?

SharedArray is special in that it will only call the initializing callback once per instance of k6 and will than let each VU to get access to the same data. Under the hood this means that the returned value is special and on access to an item returns a new JS object for the accessed element for the VU that requested it. And this only works for data that can be serialized as JSON and back.

There is no way to implement this in pure JS, and it doesn’t really make sense for this case as again this only moves data not behavior. But even if you can serialize the class instance it will still need to get a copy back out that will access the local JS VM.

# Best Practices for Class-Based K6 Scripts

Over the years I have seen a lot of users use classes as a way to organize code, and definitely some using it for the script options and the default functions. None of those should be problematic, any more than any other way of organizing code.

The only thing I have seen as a problem on some support help is users having caches that never stop growing that are some class field. That is also possible with just variables, I guess maybe with classes people might get more confused what is happening, but again not really the classes fault.

Writing test scripts is effectively programming as any other. I usually recommend people and organizations that they are writing the tests to test their systems. So it is usually more important to run the tests than to figure out the best way to write them. If you are in the early stages of writing the tests I would recommend validating that your tests work for you before trying to make them maintainable.

I think this should cover over all of the points more or less. tl;dr really no problem with any of the things you are doing, k6 scripts are programs, so the same best practices apply here as else where.

Hope this helps you !