Send your request Join Sii

Properly structuring and planning the framework’s architecture is a crucial step in designing larger projects. As our application becomes more complex and grows in size, it’s important for its foundations to be well laid out. A well-organized structure will allow for smoother development, maintenance, and scalability of our project.

Another significant aspect that we will address in our series of articles on k6 is automation. Manual code verification and testing in a larger project can be time-consuming and error-prone. Therefore, we will employ tools that enable us to automate testing and verification of our code.

Node? Go?

NPM (Node Package Manager) is a tool used to manage packages and libraries in the JavaScript environment of Node.js. It is one of the key components of the Node.js ecosystem, enabling developers to easily download, install, update, and remove packages, as well as manage their dependencies.

In previous parts, I mentioned that k6 utilizes the Go language under the hood, meaning it is not built on Node.js. This has certain consequences, as some Node.js APIs, such as fs or os modules, won’t work in k6. Similarly, browser APIs are also not available. Thus, using Node.js in the context of k6 might have limitations.

However, we must clearly distinguish between two parts of our framework – the functionalities of k6 itself and its structure. Functionalities like making HTTP requests or data operations are effectively executed in Go under the hood. To supplement any gaps in these functionalities, we have the option to create extensions, which we will focus on in the upcoming parts.

On the other hand, the framework’s structure is independent of the Go language. We can use any tool that allows us to structure, automate, and simplify our project effectively. Choosing the npm package manager was a natural choice for me, as test scripts are written in JavaScript, and npm is one of the most popular and trusted tools used by engineers for functional test automation.

Nevertheless, in practice, we can use any tool that meets the requirements described in the later parts of this article and allows us to develop our framework efficiently.

Project Initialization

We’ve discussed what Node is and the reasons behind my choice of Go for building the testing framework. Let’s move on to initializing the initial project. This is done by executing the command:

Initializing the initial project
Fig. 1 Initializing the initial project

After entering project information such as its name or description, a package.json file will be created. Its contents look as follows:

Contents of package.json file
Fig. 2 Contents of package.json file

The most interesting field for us is located within the scripts object. It holds user-defined commands that serve as shortcuts for running longer commands. We will understand exactly what this means in the upcoming sections of this article.

At this stage, let’s create a directory called “scripts” with an example script named scenario.js, which will contain a single HTTP request command along with a few unnecessary imports. Its chaotic structure is intentionally created.

A directory called scripts
Fig. 3 A directory called scripts


A linter, sometimes referred to as a static code analyzer, is a developer tool used for the automatic analysis of large sets of code to detect errors, deviations from established coding standards, and potential issues related to security or performance. Its main task is to examine code for:

  • missing elements,
  • faulty structures,
  • lack of consistency,
  • and other errors.

A linter operates at a static level, which means it analyzes code without actually running it, enabling the rapid identification of potential issues before the application is executed. This allows developers to detect and address errors earlier in the program’s development, leading to improved code quality and predictability.

When writing test scenarios in k6, we use a linter to identify potential issues in our code. In simple scenarios, this could involve detecting unused objects or imports.

Now that we understand what a linter is, let’s proceed to implement it in our script. To install the tool, we’ll use the npm package manager.

Implementation of linter in a script
Fig. 4 Implementation of linter in a script

In a linter, the rules that will be applied to our script are defined using configuration files. Let’s create a file named .eslintrc.js where we will define a part of our configuration.

Defining parts of the configuration
Fig. 5 Defining parts of the configuration

You can find a full list of options in the documentation of the tool. In the existing package.json file, let’s define two commands that will serve us to:

  1. Detect errors in all files in the script’s directory, where we store our test scenarios.
  2. Automatically fix detected errors in the specified directory.
Defining commands
Fig. 6 Defining commands

Now let’s run the first of the commands.

Running the first command
Fig. 7 Running the first command

Next, let’s try running the script fix and see what changes will be made to the scripts.

Uruchamianie naprawy skryptów
Fig. 8 Running script fix

As we can see, unnecessary elements have been removed from the code. This allows us to maintain high code quality. Unfortunately, some errors will intentionally not be fixed automatically – they require manual code review by an engineer.

The linter should be set up to run by default during the process of submitting changes to the repository to ensure code consistency and correctness.


Prettier is a code formatting tool that automatically organizes the structure of code in a specific programming language. Its main goal is to ensure consistent formatting across different parts of the code and to improve code readability and understanding.

Developers can focus on writing application logic with Prettier, and the tool will take care of the code formatting automatically. This not only enhances code readability but also saves time and effort that would otherwise be spent on manual code formatting. Prettier is a popular tool among programmers who value clean, consistent, and aesthetically pleasing code.

When writing multiple test scenarios simultaneously, Prettier finds its application in standardizing practices used by different engineers. This allows us to maintain a consistent appearance and formatting of the code throughout the project.

To install the tool, simply use the npm package manager and enter the command:

Instalowanie Prettiera
Fig. 9 Installing Prettier

Similar to the linter, the rules for how the code should be formatted are defined in various file formats. In our case, we will use the json format for configuration. The sample content of a file named .prettierrc.json looks like this:

Przykładowa zawartość pliku
Fig. 10 Sample file content

The options presented above are also the configurations that I personally use in my projects. At the same time, I highly recommend its implementation in your own frameworks.

After creating the configuration, we are ready to define two commands. The first one will be used to check the formatting, and the second one to automatically apply it.

Definiowanie poleceń
Fig. 11 Defining commands

Let’s start by checking if formatting errors will be detected.

Wykrywanie błędów
Fig. 12 Error detection

Now let’s run the automatic code formatting on the existing scenarios in the script’s directory.

Automatyczne sformatowanie kodu
Fig. 13 Automatic code formatting

Let’s check the content of our code after formatting.

Weryfikacja kodu po formatowaniu
Ryc. 14 Weryfikacja kodu po formatowaniu

Similar to the linter, Prettier should also be run at the stage of introducing changes to the repository to ensure consistent code formatting.


In this article, we focused on the initial steps of creating a sample testing framework that enables us to monitor the performance of our applications using the k6 tool. We began by installing two key tools that greatly facilitate working with our code – the linter and Prettier. Thanks to these tools, we can avoid common syntactic and logical errors and maintain clean code formatting.

In the upcoming parts of our series, we will focus on expanding our testing framework with additional elements such as configuration files and sample test scenarios.


If you haven’t had a chance to read the articles in the series yet, you can find them here:

In addition, I encourage you to check out the project’s Repository.

5/5 ( vote: 1)
5/5 ( vote: 1)
Grzegorz Piechnik

Performance Test Engineer z udokumentowanym doświadczeniem w branży bankowej, giełdowej i streamingowej. Jego praca skupiona jest głównie na pełnej automatyzacji procesów wydajnościowych oraz zarządzaniu obserwowalnością w systemach. Poza pracą prowadzi bloga dotyczącego CyberSecurity, Devops i wydajności aplikacji oraz zajmuje się rozwojem narzędzi open source. Ponadto edukuje, szkoli i wprowadza nowe osoby do branży IT

Leave a comment

Your email address will not be published. Required fields are marked *

You might also like

More articles

Don't miss out

Subscribe to our blog and receive information about the latest posts.

Get an offer

If you have any questions or would like to learn more about our offer, feel free to contact us.

Send your request Send your request

Natalia Competency Center Director

Get an offer

Join Sii

Find the job that's right for you. Check out open positions and apply.

Apply Apply

Paweł Process Owner

Join Sii


Ta treść jest dostępna tylko w jednej wersji językowej.
Nastąpi przekierowanie do strony głównej.

Czy chcesz opuścić tę stronę?