In the previous tutorials, you designed k6 scripts to assert performance and make comparing results easy.
In this tutorial, learn how to:
- Modularize test scripts into reusable components
- Dynamically configure scripts with environment variables
For fun, let's combine the scripts from the previous tutorials. Use the logic of the multiple-flows.js test with the thresholds and scenario of the api-test.js (feel free to add more checks, requests, groups, and so on). Take note of the features of this script:
- The default function has two groups, Contacts flow, and Coinflip game
- The options object has two properties, thresholds and scenarios
In the following sections, learn how to split these components into separate files, and combine them dynamically at run time.
With modules, you can use logic and variables from other files. Use modules to extract the functions to their own files.
To do so, follow these steps:
Copy the previous script (whole-tutorial.js) and save it as main.js.
Extract the Contacts flow group function from main.js script file and paste it into a new file called contacts.jscontacts.js
As is, this script won't work, since it has undeclared functions and variables.
Add the necessary imports and variables. This script uses the group, sleep, and http functions or libraries. It also has a custom metric. Since this metric is specific to the group, you can add it contacts.js.
Finally, pass baseUrl as a parameter of the contacts function.contacts.js
Repeat the process with the coinflip group in a file called coinflip.js. Use the tabs to see the final three files should (options moved to the bottom of main.js for better readability).main.jscontacts.jscoinflip.js
Run the test:
The results should be very similar to running the script in a combined file, since these are the same test.
Now that the iteration code is totally modularized, you might modularize your options, too.
The following example creates a module config.js to export the threshold and workload settings.
Notice the length of this final script and compare it with the script at the beginning of this page. Though the final execution is the same, it's half the size and more readable.
Besides shortness, this modularity lets you compose scripts from many parts, or dynamically configure scripts at run time.
With modularized configuration and logic, you can mix and match logic. An easy way to configure this is through environment variables.
Change main.js and config.js so that it:
- By default runs a smoke test with 5 iterations
- With the right environment variable value, runs a breaking test
To do this, follow these steps:
Add the workload settings for configuring the smoke test to config.js:config.js
Edit main.js to choose the workload settings depending on the WORKLOAD environment variable. For example:main.js
Run the script with and without the -e flag.
- What happens when you run k6 run main.js?
- What about k6 run main.js -e WORKLOAD=breaking?
This was a simple example to showcase how you can modularize a test. As your test suite grows and more people are involved in performance testing, your modularization strategy becomes essential to building and maintaining an efficient testing suite.
Now you've seen examples to write tests, assert for performance, filter results, and modularize scripts. Notice how the tests progress in complexity: from single endpoints to holistic tests, from small to large loads, and from single tests to reusable modules. These progressions are typical in testing, with the next step being to automate. It might be impractical to automate a tutorial, but if you are interested, read the Automated performance testing guide.