A modern load testing tool, using Go and JavaScript - https://k6.io
k6 v0.50.0
is here π!
This release:
options.cloud
option.k6/timers
module.k6/experimental/webcrypto
module.name
tag, which also overwrites the url
tag with the name
value. This change makes it consistent with the logic that was implemented in k6 v0.41. Thanks, @mkadirtan for contributing!In future releases, we are going to be moving most of the synchronous browser APIs to asynchronous ones (promisifying them). We expect this will affect most of our users, so we are posting this upfront before making the change. Here are the reasons for making this large breaking change:
You can find a list of all the APIs that we expect to convert to async in a comment in issue browser#428.
Awaiting on something thatβs not a thenable just returns that value, which means you can add the await
keyword against APIs that will become async to future proof your test scripts.
You can now upload files using the available input forms on the website under test. The new API is setInputFiles
which can be called from a page
, frame
or elementHandle
types. It can upload one or more files encoded in the test script. To upload files from the local file system, work with the experimental fs module.
For the following examples, we will use the HTML file:
<html>
<body>
<form method="POST" action="/upload" enctype="multipart/form-data">
<input type="file" name="upl" id="upload" multiple />
<input type="submit" value="Send" />
</form>
</body>
</html>
Uploading a file can be achieved with the following script:
// Import the k6 encoder module.
import encoding from 'k6/encoding';
...
export default async function () {
const page = browser.newPage();
await page.goto(url)
// Encode and upload some data into a plain text file called test.txt.
page.setInputFiles('input[id="upload"]', { name: 'test.txt', mimetype: 'text/plain', buffer: encoding.b64encode('Hello World') })
// Click on the submit button on the form to upload the file.
const submitButton = page.locator('input[type="submit"]')
await Promise.all([page.waitForNavigation(), submitButton.click()])
page.close();
}
Uploading multiple files can be done with the use of an array:
page.setInputFiles('input[id="upload"]',
[{ name: 'test.txt', mimetype: 'text/plain', buffer: encoding.b64encode('Hello World') },
{ name: 'test.json', mimetype: 'text/json', buffer: encoding.b64encode('{"message": "Hello World"}') }])
Thanks to @bandorko! :bow: :tada:
In this release, we introduce a new way of defining cloud options. From now on, you can use options.cloud
instead of options.ext.loadimpact
.
To migrate, you can move the loadimpact
object to the root of the options
object and rename it to cloud
. For example:
export let options = {
ext: {
loadimpact: {
name: "Legacy way of defining cloud options",
projectID: 12345,
}
}
};
export let options = {
cloud: {
name: "Current way of defining cloud options",
projectID: 12345,
}
};
All scripts with legacy options.ext.loadimpact
will continue to function as before. There's no planned sunset date for the legacy option, but we highly encourage using options.cloud
going forward. For more details about cloud options, refer to Cloud options.
With this release, the timers API is no longer experimental and can be imported as k6/timers
instead of as k6/experimental/timers
. The later will be supported until v0.52.0
.
You can also contribute to the discussion on making the current timer exports globally available in #3589, or just give it a :+1:.
k6/experimental/webcrypto
module webcrypto#61The experimental webcrypto module now supports the JSON Web Key (JWK) format, using the importKey
and exportKey
methods.
This allows you to import and export keys in the JWK format for the supported algorithms.
const generatedKey = await crypto.subtle.generateKey({name: "AES-CBC", length: "256"}, true, [ "encrypt", "decrypt"]);
const exportedKey = await crypto.subtle.exportKey("jwk", generatedKey);
evaluate
APIs.testRunId
into the window.k6
object for external applications to query (for example, Grafana Faro).With this release, we have overhauled and (tremendously) improved the performance and stability of the browser module. It's now possible to run tests with a larger number of VUs concurrently without any performance issues. Previously, when running tests with multiple VUs concurrently, each VU's browser context would attach to the pages from the other VUs' browser contexts. This led to unexpected behavior and performance issues and, to an extent, reduced the module's capability to run multi-VU tests.
options.hosts
.DocumentFragment
.codeql
GitHub action to v3.newTestSetup
rely on k6's modulestest.k6 v0.49.0
is here π! This release:
clear
functionality to the browser module's locator
classes.k6/html
.k6/experimental/timers
for stabilization.loadimpact/k6
docker image. If you still use it, please migrate to the grafana/k6 image.timeout
option for isVisible
and isHidden
since the API no longer waits for the element to appear on the page.The new web dashboard brings real-time visualization to load testing. This feature allows users to monitor test progress and analyze results dynamically, enhancing the overall testing experience.
Activate this feature using the environment variable K6_WEB_DASHBOARD=true
. For this initial release, the dashboard is not enabled by default to allow users to opt into this new experience as it evolves.
K6_WEB_DASHBOARD=true k6 run script.js
Once enabled and the test script is running, navigate to http://localhost:5665 in your web browser to access the dashboard.
The web dashboard also offers an HTML test report (see an example) for detailed analysis, enabling easy sharing and downloading capabilities for collaboration.
To access and download the report, click on the Report button in the dashboard's top right corner or use the K6_WEB_DASHBOARD_EXPORT
environment variable.
K6_WEB_DASHBOARD=true K6_WEB_DASHBOARD_EXPORT=test-report.html k6 run script.js
clear
to the locator
class browser#1149The new clear
method on the locator
class clears the text boxes and input fields. This is useful when navigating to a website where the text boxes and input fields already contain a value that needs to be cleared before filling it with a specific value.
import { check } from 'k6';
import { browser } from 'k6/experimental/browser';
export const options = {
scenarios: {
ui: {
executor: 'shared-iterations',
options: {
browser: {
type: 'chromium',
},
},
},
},
}
export default async function() {
const context = browser.newContext();
const page = context.newPage();
await page.goto('https://test.k6.io/my_messages.php', { waitUntil: 'networkidle' });
// To mimic an input field with existing text.
page.locator('input[name="login"]').type('admin');
check(page, {
'not_empty': p => p.locator('input[name="login"]').inputValue() != '',
});
// Clear the text.
page.locator('input[name="login"]').clear();
check(page, {
'empty': p => p.locator('input[name="login"]').inputValue() == '',
});
page.close();
}
The browser module now generates traces that provide a representation of its inner workings, such as API methods executed (for example browser.newPage
and page.goto
), page navigations, and Web Vitals measurements.
Currently, the instrumented methods are a subset of all the methods exposed by the browser module API, but this will be extended in the future.
The traces generation for the browser module depends on the overall k6
traces option introduced in v0.48.0. Check out the documentation to learn more about it.
With this release, gRPC's streaming API becomes part of the core's k6/net/grpc
module. The experimental k6/experimental/grpc
has been back-merged into the core.
You can still use import k6/experimental/grpc
for a couple of releases, but it's deprecated and will be removed in the future (planned in k6 version v0.51.0
).
To migrate your scripts, replace k6/experimental/grpc
with k6/net/grpc
in your script imports, and the code should work as before.
k6/html
has been around for a while and allows you to search within an HTML document with a jQuery-like API called Selection, and also has support for the more standard Element that represents DOM element.
For a long time, you could get an Element from a Selection using the .get(index)
, but you couldn't get back to a Selection from an Element.
This is not a common case, but one that requires quite a bit of code. For example, see the following jQuery snippet:
let li = http.get("https://test.k6.io").html().find("li");
li.each(function(_, element) {
// here element is an element not a selection
// but what if for each li we want to select something more?
// in jquery that will be:
let container = $(element).closest('ul.header-icons');
// but what should `$` do?
// in a browser there is only 1 html document that you have access to
// in k6 though you can be working with multiple ones, so `$` can't know which one it should
// work against
});
In order to support the above example, you can use selection
, without going to the element:
let li = http.get("https://test.k6.io").html().find("li");
for (; li.size() > 0; li = li.next()) {
let ul = li.closest('ul.header-icons'); // li here is still a selection and we iterate over it.
}
This is not always possible though, and arguably isn't what most users will naturally do.
Because of this, we have now added a new .selection()
which returns a selection for its element.
let li = http.get("https://test.k6.io").html().find("li");
li.each(function(_, element) {
let container = element.selection().closest('ul.header-icons');
// .. more code
});
Thanks to @Azhovan! :bow: :tada:
k6 now collects usage data of the modules and outputs that are being used when the usage report is enabled. The data collection is only related to the built-in k6 modules and outputs. Private, custom modules and extensions are never collected. The usage report is enabled by default in k6, but it is possible to opt-out using the no-usage-report option.
We always want to improve the product, but at the same time, we need to pay attention to where we allocate our resources. Having data of what are the most used modules and outputs gives us better confidence to make decisions because we are supported by data. The data can let us know what percentage of our users will benefit from the introduction of a new feature and also, how many of them would be impacted in case of a breaking change.
@mem
for working on it!console
in the k6 logs.grafana.com/docs/k6/latest/
.console
.BigInt
parsing.isVisible
and isHidden
so that it doesn't wait for an element to match with the given selector
, allowing it to continue on with the test script when elements are not on the page.dblClick
so that it works with onDblClick
and performs two clicks on the specified element.CODEOWNERS
from GitHub Action.open
and require
and their handling of paths.As mentioned earlier, there's work in progress to make xk6-timers stable as part of the next release. You can find more information on issue #3297.
k6 v0.48.0 is here π! This release includes:
k6 new
subcommand to generate a new test script.k6/experimental/fs
module for file interactions.This release includes several breaking changes, mainly cleaning up deprecations from previous versions. They should have a straightforward migration process, and not heavily impact existing users.
Client
signature in k6/experimental/redis
module. Refer to the module-related section below.grpc.invoke()
's parameter headers
, deprecated in k6 v0.37. Use the metadata
parameter instead.--logformat
flag, deprecated in v0.38. Use the --log-format
flag instead.k6 convert
CLI command, deprecated in v0.41. Use the har-to-k6 package instead.https://
scheme to module specifiers that were not recognized. Deprecated in k6 v0.25. Use full URLs if you want to load remote modules instead.k6 new
subcommand #3394k6
now has a new
subcommand that generates a new test script. This is useful for new users who want to get started quickly, or for experienced users who want to save time when creating new test scripts. To use the subcommand, open your terminal and type:
k6 new [filename]
If no filename is provided, k6 uses script.js
as the default filename. The subcommand will create a new file with the provided name in the current directory, and populate it with a basic test script that can be run with k6 run
.
k6/experimental/fs
module #3165k6
now has a new k6/experimenal/fs
module providing a memory-efficient way to handle file interactions within your test scripts. It currently offers support for opening files, reading their content, seeking through it, and retrieving metadata about them.
Unlike the traditional open function, which loads a file multiple times into memory, the filesystem module reduces memory usage by loading the file as little as possible, and sharing the same memory space between all VUs. This approach significantly reduces the memory footprint of your test script and lets you load and process large files without running out of memory.
For more information, refer to the module documentation.
This example shows the new module usage:
import fs from 'k6/experimental/fs';
// k6 doesn't support async in the init context. We use a top-level async function for `await`.
//
// Each Virtual User gets its own `file` copy.
// So, operations like `seek` or `read` won't impact other VUs.
let file;
(async function () {
file = await open('bonjour.txt');
})();
export default async function () {
// About information about the file
const fileinfo = await file.stat();
if (fileinfo.name != 'bonjour.txt') {
throw new Error('Unexpected file name');
}
const buffer = new Uint8Array(128);
let totalBytesRead = 0;
while (true) {
// Read into the buffer
const bytesRead = await file.read(buffer);
if (bytesRead == null) {
// EOF
break;
}
// Do something useful with the content of the buffer
totalBytesRead += bytesRead;
// If bytesRead is less than the buffer size, we've read the whole file
if (bytesRead < buffer.byteLength) {
break;
}
}
// Check that we read the expected number of bytes
if (totalBytesRead != fileinfo.size) {
throw new Error('Unexpected number of bytes read');
}
// Seek back to the beginning of the file
await file.seek(0, SeekMode.Start);
}
In this release, the k6/experimental/redis
module receives several important updates, including breaking changes.
The Client
constructor now supports connection URLs to configure connections to Redis servers or clusters. These URLs can be in the format redis://[[username][:password]@][host][:port][/db-number]
for standard connections, or rediss://[[username][]:password@]][host][:port][/db-number]
for TLS-secured connections. For more details, refer to the documentation.
import redis from 'k6/experimental/redis';
const redisClient = new redis.Client('redis://someusername:somepassword@localhost:6379/0');
The Client
constructor has been updated with a new Options object format. This change aligns the module with familiar patterns from Node.js and Deno libraries, offering enhanced flexibility and control over Redis connections. For more details, refer to the documentation.
This example shows the usage of the new Options
object:
import redis from 'k6/experimental/redis';
const redisClient = new redis.Client({
socket: {
host: 'localhost',
port: 6379,
},
username: 'someusername',
password: 'somepassword',
});
The Redis module now includes (m)TLS support, enhancing security for connections. This update also improves support for Redis clusters and sentinel modes (failover). For connections using self-signed certificates, enable k6's insecureSkipTLSVerify option (set to true
).
This example shows the configuration of a TLS connection:
import redis from 'k6/experimental/redis';
const redisClient = new redis.Client({
socket: {
host: 'localhost',
port: 6379,
tls: {
ca: [open('ca.crt')],
cert: open('client.crt'), // client certificate
key: open('client.key'), // client private key
},
},
});
k6
now supports a new traces output option that allows you to configure the output for traces generated during its execution. This option can be set through the --traces-output
argument in the k6 run
command or by setting the K6_TRACES_OUTPUT
environment variable.
Currently, no traces are generated by k6
itself, but this feature represents the first step towards richer tracing functionalities in k6
and its extensions.
By default traces output is set to none
, and currently the only supported output is otel
which uses the opentelemetry-go's Open Telemetry API and SDK implementations. The format for the otel
traces output configuration is the following:
--traces-output=<endpoint>[,opt1=val1,opt2=val2]
Where opt
s can be one of the following options:
proto
: Specifies the protocol to use in the connection to the traces backend. Supports grpc
(default) and http
.header.<header_name>
: Specifies an additional header to include in the connection to the traces backend.Example:
K6_TRACES_OUTPUT=https://traces.k6.io/v1/traces,proto=http,header.Authorization=Bearer token
page.throttleCPU
browser#1095The browser module now supports throttling the CPU from chrome/chromium's perspective by using the throttleCPU
API, which helps emulate slower devices when testing the website's frontend. It requires an argument of type CPUProfile
, which includes a rate
field that is a slow-down factor, where 1
means no throttling, 2
means 2x slowdown, and so on. For more details, refer to the documentation.
...
const context = browser.newContext();
const page = context.newPage();
try {
page.throttleCPU({ rate: 4 });
...
page.throttleNetwork
browser#1094The browser module now supports throttling the characteristics of the network from chrome/chromium's perspective by using the throttleNetwork
API, which helps emulate slow network connections when testing the website's frontend. It requires an argument of type NetworkProfile
, with a definition of:
export interface NetworkProfile {
/*
* Minimum latency from request sent to response headers received (ms).
*/
latency: number;
/*
* Maximal aggregated download throughput (bytes/sec). -1 disables download
* throttling.
*/
download: number;
/*
* Maximal aggregated upload throughput (bytes/sec). -1 disables upload
* throttling.
*/
upload: number;
}
You can either define your own network profiles or use the ones we have defined by importing networkProfiles
from the browser
module. For more details, refer to the documentation.
import { browser, networkProfiles } from 'k6/experimental/browser';
...
const context = browser.newContext();
const page = context.newPage();
try {
page.throttleNetwork(networkProfiles['Slow 3G']);
...
It's not directly part of the k6 v0.48 release, but we believe it is worth mentioning that we're moving the documentation from k6.io/docs to grafana.com/docs/k6.
The legacy documentation space k6.io/docs
will be available for a while, but we encourage you to update your bookmarks and links to the new domain.
browser.closeContext()
method to facilitate closing the current active browser context.--profiling-enabled
which enables exposing pprof profiling endpoints. The profiling endpoints are exposed on the same port as the HTTP REST API under the /debug/pprof/
path. This can be useful for extension developers.--version
flag, which has the same output as k6 version
command. Thanks, @ffapitalle!K6_INFLUXDB_PROXY
to the InfluxDB output which allows specifying proxy. Thanks, @IvanovOleg!-o cloud
.fsext.Abs
helper function.console.debug()
, aligning -v
output to --console-output
and stdout
.handleSummary()
.content-encoding
header and HTTP statuses known for having no body.browserContext.clearPermissions
to clear permissions without panic.browserContext.waitForEvent
which involved promisifying the waitForEvent
API.page.$
so that it returns null
when no matches with given selector are found.goja
dependency. Fixes a possible panic and proper handling circular types at JSON.stringify
. Fixes an issue about dumping the correct stack trace when an error is re-thrown.iframe
s. Thanks, @bandorko!gh
in GitHub actions creating the OSS release.js
package.make ci-like-lint
in favor of make lint
. Updates a golangci-lint version to v1.55.2.tests
reference in the all rule of the Makefile. Thanks, @flyck!k6 cloud
.clearPermissions
and grantPermissions
.force
and noWaitAfter
in frame.newAction
.TestSetupTimeout
test.lib/strvals
package.It has been a while since we've introduced the k6/experimental
namespace. This namespace was specifically created to test new features before we fully committed to them. Thanks to it, we have been able to iterate on features and receive valuable feedback from the community before adding them to the core of k6.
In the following releases, we're going to graduate k6/experimental/grpc
and k6/experimental/timers
.
These modules' "experimental" versions will remain available for a couple of releases, but the goal is to remove the "experimental" imports for them in favor of the core-only imports.
We're happy to announce our work on a new, upcoming dashboard feature. Based on the xk6-dashboard extension, this upcoming feature will enable you to visualize your test runs and their results in your web browser, in real time. The k6 maintainers team is starting to work towards its integration into the core of k6, and we're aiming to release it in the next couple of releases.
While the final user-experience might differ, you can already try it out by following the instructions in the xk6-dashboard repository. We update the extension on a regular basis as we're converging towards the first release of the feature in k6. Go ahead and give it a try! Let us know what you think about it!
k6 v0.47.0
is here π! This release includes:
statsd
output option has been deprecated, and users should use the xk6-output-statsd extension instead. See #2982 for future plans.https://
. Before, k6 would try to resolve importing remote modules by prepending https://
if it was missing. This behavior has been deprecated and will be fully removed in the next release (v0.48.0).The k6 gRPC modules (k6/net/grpc
and k6/experimental/grpc
) now support handling binary metadata that uses the -bin
postfix, according to the gRPC specification.
let resp = client.invoke("grpc.testing.TestService/EmptyCall", {}, { metadata: { "X-Load-Tester-bin": new Uint8Array([2, 200]) } })
Thanks to @sapphire-janrain for the contribution!
The k6 gRPC modules (k6/net/grpc
and k6/experimental/grpc
) now support adding metadata to reflection requests by using a new connection parameter reflectMetadata
.
Grafana Cloud k6 is now able to store and visualize Trend metrics up to 3 digits of precision for decimal numbers.
k6 is now publishig Docker images that include Chromium web browser. This allows k6 users to run tests that use Browser API without having to install Chrome first. Check the "A note on running browser tests" section of the Overview page on DockerHub for details.
The k6's release process now builds and pushes dedicated Docker images for ARM64. Check k6's tags page on DockerHub for details.
The experimental Prometheus remote write output now supports two new authentication methods: Bearer token and TLS certificates. Check out the documentation to learn more about how to define them using the new environment variables.
We've also added the K6_PROMETHEUS_RW_HTTP_HEADERS
that defines a new and more convenient way to set custom HTTP headers to pass through each flush metrics' request.
The browser module now provides a more complete and robust API for handling cookies. The cookie API was stabilized by defining a new Cookie
class (browser#1008, browser#1030) that can be used while creating and retrieving cookies. This enabled us to add a new browserContext.cookies([urls])
method (browser#1005) that returns all cookies from the current browser context. The new API also supports filtering cookies by URL (browser#1016).
That led to fixing a bug where the expires
field was not being set correctly while adding cookies using the context.addCookie()
method (browser#1031). Lastly, the existing context.clearCookies()
method was fixed to clear all cookies from the current browser context (browser#1040).
const context = browser.newContext();
context.addCookies([
{name: 'foo', value: 'bar', url: 'https://test.k6.io'},
{name: 'baz', value: 'qux', url: 'https://grafana.com'},
]);
const cookies = context.cookies('https://test.k6.io');
console.log(cookies.length); // 1
console.log(cookies[0].name); // foo
console.log(cookies[0].value); // bar
context.clearCookies();
console.log(context.cookies.length); // 0
page.on('console')
browser#1006Allows users to register a handler to be executed every time the console
API methods are called from within the page's JavaScript context. The arguments passed into the handler are defined by the ConsoleMessage class.
page.on('console', msg => {
check(msg, {
'assertConsoleMessageType': msg => msg.type() == 'log',
'assertConsoleMessageText': msg => msg.text() == 'this is a console.log message 42',
'assertConsoleMessageArgs0': msg => msg.args()[0].jsonValue() == 'this is a console.log message',
'assertConsoleMessageArgs1': msg => msg.args()[1].jsonValue() == 42,
});
});
page.evaluate(() => console.log('this is a console.log message', 42));
setup
and teardown
via REST API. Thanks to @kmtym1998 for the contribution!k6 version
.*-with-browser
Docker images to automatically set the no-sandbox
environment variable.k6
object (window.k6 = {};
) to help identify k6 browser module tests.check
in examples/fillform.js
so that it matches the type definitions and documentation for check
.goja
version, and fixes a compiler bug when a class is declared in a function with an argument.goja
conversions while adding and retrieving cookies.page.reload
& page.setContent
to use the default navigation timeout over the default timeout.page
timeouts so it is actually used after being set.interfacebloat
linter.goja
, includes runtime initialization speed-up and a fix for source indexes.alpine
image version that is used as the base of the k6 Docker image.int64
timeout to time.Duration
, to help avoid confusion as to whether a timeout is in milliseconds or seconds.Work on this epic issue has been picked up and there is some progress in the underlying implementation.
One of the main internal changes will be dropping Babel, which is currently used to transpile ESM code to CommonJS.
For users, it will mean better JavaScript support as this change will automatically get object spread working and likely faster startup for big scripts. In the future, this also means JavaScript compatibility will be easier to add, since it'll only need to be supported in the JavaScript VM we use - goja.
There's a risk that some k6 tests using both CommonJS and ECMAScript modules syntax will change in behavior. In practice, using both should never really be done as they're not compatible.
Because there are risks involved, we are going to do this very carefully and only once we have done a lot of tests. That means this is currently planned for v0.49.0, but with the majority of the remaining work done in the v0.48.0 cycle.
This way, we will also be able to have most of our users test these changes from our master
branch, using Docker images, for example.
There are several changes in the next release that are entering the final stage of their deprecation period. That means the next release will include the following breaking changes:
k6 converter
command will be removed.headers
param for the gRPC module will be removed. Users should use the metadata property instead.https://
protocol in their URLs, otherwise it will return an error.file_name
).--logformat
flag for defining the Log format option will be removed. --log-format should be used instead.We recommend checking this list to see if you are impacted, and updating your scripts or CI/CD processes to avoid any issues. If you have any feedback, please open an issue.
k6 v0.46
is here π! This release includes:
v1.0.2
, which includes breaking changes.In this release, the xk6-browser extension version is bumped up to v1.0.2
, as it includes multiple breaking changes concerning options, browser lifecycle, and metrics. See the migration guide for making your test scripts compatible with the new version.
Options devtools
, env
and proxy
are deprecated (browser#868, browser#870, browser#872). Additionally, browser launch
/connect
options are no longer defined in the corresponding JS API methods, instead the test execution related options are now defined inside the browser scenario options (see #3036), and the other more "environmental options", such as headless
, debug
, executablePath
, are set as ENV vars. Also, the slowMo
option is no longer supported, although it might be supported again in the future through a different API (browser#876).
Metrics also went through a few changes. The Web Vitals metrics are renamed to use the browser_
prefix and short namings (e.g.: webvital_first_input_delay
-> browser_web_vital_fid
) (browser#885, browser#903), and the rating metric is removed, as it is now set as a label in the corresponding Web Vitals metrics (browser#915).
The browser HTTP metrics have also been modified, as these are now split from the HTTP module ones, so there are new browser_
prefixed HTTP metrics, specifically for request duration and failed requests (browser#916).
Another big change introduced in this version affects the way the browser lifecycle is handled. Users no longer have to explicitly initialize/close the browser instance through the JS API. Instead, a browser instance will be automatically initialized/closed at the beginning/end of each iteration if the browser type is set in scenario options (see #3036). This also means that the chromium
entity from k6/experimental/browser
import path is no longer valid. Instead, the browser
entity provides access to the browser methods such as browser.newPage()
(browser#910, browser#944). This change means that the browser.on()
method is no longer applicable, and therefore it has been removed (browser#919).
Additionally, related to import changes, the browser module version is no longer an exported field (browser#923).
Last but not least, this release also includes constraints on browser contexts usage as now only one browserContext
is allowed per iteration, which means that the user can create a new browserContext
, close it, and then create it again; but can not have more than one "live" browserContext
. Instead, scenarios should be used to separate independent actions in a test (browser#929, browser#945).
With all these changes, a simple browser test now looks like:
import { browser } from 'k6/experimental/browser';
export const options = {
scenarios: {
ui: {
executor: 'shared-iterations',
options: {
browser: {
type: 'chromium', // chromium is the only supported browser type so as long as
// the option is set, Chromium/Google Chrome will be used
},
},
},
},
};
export default async function () {
const page = browser.newPage();
try {
await page.goto('https://grafana.com')
} finally {
page.close();
}
}
loadimpact/k6
docker image. We recommend switching to the grafana/k6
image as soon as possible.k6 has been able to send logs to Loki for nearly 3 years since v0.28.0 but didn't support any way to authenticate.
Now, it can be configured to send additional headers on every request.
This can be done by using the new header
config option, similar to label
:
k6 --log-output=loki=http://example.org,header.X-My-Header=123,header.Authorization=mytoken ...
The example above will now send the header X-My-Header
with the value 123
and the Authorization
header with the value mytoken
.
Thanks to @federicotdn for adding this feature.
This release supports the new integration between k6 and Tempo in the cloud. Grafana Cloud k6 and Grafana Cloud Tempo customers will be able to start their traces in k6 using the existing k6/experimental/tracing
module to enrich their test run analysis page with metrics and aggregations from tracing data.
The new Cloud traces will work "out of the box" for k6 cloud
runs. In case of k6 run
execution, the K6_CLOUD_TRACES_ENABLED
environment variable has to be set to true
.
The k6/net/grpc
and k6/experimental/grpc
modules now support configuring TLS per-connection via ConnectParams. This is useful when connecting to a single gRPC server, using different TLS settings for each VUs, as well as when connecting to multiple gRPC servers from the same VU.
import grpc from "k6/experimental/grpc";
import { check } from "k6";
import { SharedArray } from "k6/data";
import exec from "k6/execution";
// note: the services in this example don't exist. If you would like
// to run this example, make sure to replace the URLs, and
// the cacerts, cert, key, and password variables.
const grpcArgs = new SharedArray("grpc", () => {
// Using SharedArray here so that not every VU gets a copy of every certificate a key
return [
{
host: "foo1.grpcbin.test.k6.io:9001",
plaintext: false,
params: {
tls: {
cacerts: [open("cacerts0.pem")],
cert: open("cert0.pem"),
key: open("key0.pem"),
},
},
},
{
host: "foo2.grpcbin.test.k6.io:9002",
params: {
plaintext: false,
tls: {
cacerts: open("cacerts1.pem"),
cert: open("cert1.pem"),
key: open("key1.pem"),
password: "cert1-passphrase",
},
},
},
];
});
const client = new grpc.Client();
export default () => {
if (__ITER === 0) {
// Take one config and use it for this one VU
let grpcArg = grpcArgs[exec.vu.idInTest % grpcArgs.length];
client.connect(grpcArg.host, grpcArg.params);
}
const response = client.invoke("hello.HelloService/SayHello", {
greeting: "Bert",
});
check(response, {
"status is OK": (r) => r && r.status === grpc.StatusOK,
});
console.log(JSON.stringify(response.message));
};
Thanks @chrismoran-mica for the contribution πββοΈ.
After years of great service, we decided to refresh the k6 Cloud output introducing a more efficient end-to-end solution for ingesting the generated tests' metrics. The main change regards the protocol used for flushing metrics that is now a binary-based payload over HTTP.
The new output reduces the resources a load generator uses for tests that produce many metrics. There is no significant difference in the user experience; it's expected to be the same.
The one thing worth highlighting is that the new output is strict about tags, and it'll drops tags if they are reserved. For example:
test_run_id
, since that is reserved for internal k6 Cloud operations__
), that is marked by Prometheus convention as reservedThis is not yet the default Cloud output for the test runs executed from local machines (k6 run -o cloud
), but it is expected to be transparently enabled in the upcoming weeks.
The full list of related PRs: #3104, #3108, #3120, #3125, #3162, #3169, #3182, #3186, #3187, #3193, #3195, #3206, #3226, #3157, #3172.
js/promises
package, which enables extension developers to easily create promises that will be dispatched to the eventloop using the New
function.RunOnEventLoop
method to the modulestest.Runtime
type, which allows extensions developers to run code on the event loop from their tests.browser_http_req_failed
metric.locator
. Thanks to @tmc for its implementation.1.0
when not set by the user.frameNavigated
.pagehide
event evaluation when page.close()
is called.browser.close()
panic.K6_INSTANCE_SCENARIOS
environment variable.os.LookupEnv
for k6 LookupEnv
and abstracts environment variables lookup.k6 v0.45.1 is a patch release that fixes the build process for extensions:
There are no functional changes in k6 compared to v0.45.0.
k6 v0.45.0 is here π! This release includes:
There is a new experimental module k6/experimental/grpc
. It is a copy of the k6/net/grpc
module with added stream support #2020.
This example shows server streaming:
import { Client, Stream } from 'k6/experimental/grpc';
import { sleep } from 'k6';
const COORD_FACTOR = 1e7;
// to run this sample, you need to start the grpc server first.
// to start the grpc server, run the following command in k6 repository's root:
// go run -mod=mod examples/grpc_server/*.go
// (golang should be installed)
const GRPC_ADDR = __ENV.GRPC_ADDR || '127.0.0.1:10000';
const GRPC_PROTO_PATH = __ENV.GRPC_PROTO_PATH || '../../grpc_server/route_guide.proto';
let client = new Client();
client.load([], GRPC_PROTO_PATH);
export default () => {
client.connect(GRPC_ADDR, { plaintext: true });
const stream = new Stream(client, 'main.FeatureExplorer/ListFeatures', null);
stream.on('data', function (feature) {
console.log(
'Found feature called "' +
feature.name +
'" at ' +
feature.location.latitude / COORD_FACTOR +
', ' +
feature.location.longitude / COORD_FACTOR
);
});
stream.on('end', function () {
// The server has finished sending
client.close();
console.log('All done');
});
stream.on('error', function (e) {
// An error has occurred and the stream has been closed.
console.log('Error: ' + JSON.stringify(e));
});
// send a message to the server
stream.write({
lo: {
latitude: 400000000,
longitude: -750000000,
},
hi: {
latitude: 420000000,
longitude: -730000000,
},
});
sleep(0.5);
};
You can just replace k6/net/grpc
import with k6/experimental/grpc
to use the new functionality. Documentation for the module is available here.
In the future, this functionality will be moved to the k6/net/grpc
module.
For years users have wanted to be able to update the test that is saved in the cloud but not run it at this exact point.
This is now possible by adding --upload-only
when invoking k6 cloud
as in k6 cloud --upload-only script.js
.
This is likely going to be most useful in a CI on the actual test script project. Now that CI can just run k6 cloud --upload-only new-version-of-script.js
on "release".
And later on that newer version will be used. For example by a scheduled run.
Support for high-cardinality metrics metadata was added in v0.41.0, but it wasn't accessible from test scripts. It's now possible to set or delete metadata for the whole VU with a similar API as used for tags:
import exec from "k6/execution";
export default () => {
exec.vu.metrics.metadata["my_cool_id"] = "a very unique value";
// all metrics from here on will have this metadata set
delete exec.vu.metrics.metadata["my_cool_id"];
// all metrics from here on will *not* have the metadata set
}
This also introduces the sub-object metrics
on the vu
object.
Apart from metadata
it has another property tags
. This is meant to be the new way to set tags instead of using exec.vu.tags
.
There are no current plans to replace exec.vu.tags
with exec.vu.metrics.tags
.
JSON.parse
will now fail with a friendlier error message.Locator.WaitFor
for detached
and hidden
states.null
.scenarios
for usage by browser module.the
. Thank you, @cuishuang π..golangci.yml
for PRs from forks..golangci.yml
.k6/data
module tests.We're excited to share our public roadmap, outlining the upcoming features and improvements we have planned.
We hope this updated roadmap provides a clear overview of our plans for k6's future development. As always, we welcome feedback, corrections, and suggestions to make this roadmap more comprehensive, accessible, and valuable for the k6 community.
Work on a new version of the cloud output has been ongoing over this cycle.
While functionally it is now mostly complete, we feel like more testing is still needed and some smaller issues need to be ironed out.
Over the next cycle we will be testing it internally, and in v0.46.0 it will be generally available as the default Cloud output. It will still be possible to use the current version via an option, but we plan to gradually deprecate it.
The new output has some benefits over the previous one:
This in general makes the payload sent for tests with a lot of samples much smaller, which also in most cases has turned out to lower the CPU and memory usage.
Other related PRs: #3041, #3061, #3063, #3072, #3082, #3083, #3085, #3098, #3105
k6 v0.44.1 is a patch release that fixes a couple of packaging issues:
ca-certificates
version.There are no functional changes in k6 compared to v0.44.0.
k6 v0.44.0 is here! π This release includes:
k6/experimental/webcrypto
module implementing (partially) the Web Crypto API specification.Some highlights from the k6/experimental/browser
module are:
locator.click
is now asynchronous, which is a breaking change.browserContext.addCookies
has now been implemented.browserType.Connect
has been implemented so k6 can now connect to an already running Chrome/Chromium browser instance.The browser module is still in an experimental
stage, and therefore breaking changes are expected as we are improving the APIs to make them more user-friendly.
browser#790 Converted locator.click
to async to have feature parity with page.click
and elementHandle.click
. Users must remember to work with promise.All
and page.waitForNavigation()
when a click action results in navigation.
A locator.click
action that doesn't result in navigation can be used like so:
const tails = page.locator("input[value='Bet on tails!']");
await tails.click(),
A locator.click
action that does result in a navigation can be used like so:
const tails = page.locator("input[value='Bet on tails!']");
await Promise.all([
page.waitForNavigation(),
tails.click(),
]);
browser#817 We've removed --no-sandbox
from the default Chrome launch arguments. Now Chrome will launch with a sandbox, which is a more secure way of running the browser. If you are running tests under a root
user, the browser will no longer launch unless the --no-sandbox
argument is supplied. You can still pass this flag when launching a new Chrome instance using the args
parameter on chromium.launch
:
const browser = chromium.launch({
args: ['no-sandbox'],
});
browser#844 Removed the exported version
param from the root module. Users should from now on reference the k6 version instead of the browser module version.
browser#838 Removed the first meaningful paint metric. This metric is being deprecated across all the browsers, because the metric's definition relies on browser-specific implementation details, and we've now introduced web vitals in the browser module which is a reliable industry standard way to measure frontend performance. You can find more details here.
browser#843 Removed the build step from Github Actions. From this release onwards, no new standalone browser binaries will be built and available from the releases section. The latest version of the browser module will be available in the k6 binary which can be found in the k6 releases page.
k6/experimental/webcrypto
module implementing the Web Crypto API specification #3007This release includes a new k6/experimental/webcrypto
module partially implementing the Web Crypto API specification in k6.
This example shows encrypting and decrypting of a "Hello, World!" string using AES-CBC algorithm.
import { crypto } from 'k6/experimental/webcrypto';
export default async function () {
const key = await crypto.subtle.generateKey(
{
name: 'AES-CBC',
length: 256,
},
true,
['encrypt', 'decrypt']
);
const encoded = stringToArrayBuffer('Hello, World!');
const iv = crypto.getRandomValues(new Uint8Array(16));
const ciphertext = await crypto.subtle.encrypt(
{
name: 'AES-CBC',
iv: iv,
},
key,
encoded
);
const plaintext = await crypto.subtle.decrypt(
{
name: 'AES-CBC',
iv: iv,
},
key,
ciphertext
);
console.log(
'deciphered text == original text: ',
arrayBufferToHex(plaintext) === arrayBufferToHex(encoded)
);
}
function arrayBufferToHex(buffer) {
return [...new Uint8Array(buffer)].map((x) => x.toString(16).padStart(2, '0')).join('');
}
function stringToArrayBuffer(str) {
var buf = new ArrayBuffer(str.length * 2); // 2 bytes for each char
var bufView = new Uint16Array(buf);
for (var i = 0, strLen = str.length; i < strLen; i++) {
bufView[i] = str.charCodeAt(i);
}
return buf;
}
You can see the list of currently supported APIs and algorithms in the project's README. Documentation for the module is available here.
This release adds sampling capabilities to the tracing module. You can now specify a sampling rate with the sampling
option when initializing a Client, or in the tracing.InstrumentHTTP
function.
browserContext.addCookies
browser#760Cookies can now be added to a BrowserContext
and all new Page
s created from this context will have the cookie assigned to them. Thanks @zucchinho for implementing this feature!
const context = browser.newContext()
context.addCookies([{name: 'myCookie', value: 'hello world', url: 'https://test.k6.io'}])
const page = context.newPage()
browserType.Connect
browser#800There are cases where the user may want to connect to a remote browser instance where they have more control over the browser lifecycle, such as when working in a resource bound environment. This feature enables users to connect to a manually started Chrome/Chromium browser instance. It's a simple case of replacing browser.launch
with browser.connect
and supplying the CDP url as the first argument. Not all launch
options will work with connect
since the browser instance should already have started prior to working with connect
. Since we assume that the user had decided to take ownership of starting the browser, we have made browser.close
a NOOP when working with browser.connect
, so the user will need to close the browser themselves.
const browser = chromium.connect('ws://127.0.0.1:1234/devtools/browser/e3bb7e53-ad0f-46f3-ae89-a8416868f4ce')
const page = browser.newPage();
Web vitals are the defacto way for developers to measure their frontend performance using the core metrics:
These measurements are now calculated for all tests without any additional work from your side. Simply run your test as you have been doing and you will be presented with the new metrics in the output. This is the output after running the examples/fillform.js script:
webvital_cumulative_layout_shift..........: avg=0 min=0 med=0 max=0 p(90)=0 p(95)=0
webvital_cumulative_layout_shift_good.....: 1 0.323332/s
webvital_first_contentful_paint...........: avg=278.86ms min=141.1ms med=229.39ms max=466.1ms p(90)=418.76ms p(95)=442.43ms
webvital_first_contentful_paint_good......: 3 0.969995/s
webvital_first_input_delay................: avg=300Β΅s min=200Β΅s med=300Β΅s max=399.99Β΅s p(90)=379.99Β΅s p(95)=389.99Β΅s
webvital_first_input_delay_good...........: 2 0.646663/s
webvital_interaction_to_next_paint........: avg=16ms min=16ms med=16ms max=16ms p(90)=16ms p(95)=16ms
webvital_interaction_to_next_paint_good...: 1 0.323332/s
webvital_largest_content_paint............: avg=303.6ms min=141.1ms med=303.6ms max=466.1ms p(90)=433.6ms p(95)=449.85ms
webvital_largest_content_paint_good.......: 2 0.646663/s
webvital_time_to_first_byte...............: avg=205.23ms min=104.79ms med=188.39ms max=322.5ms p(90)=295.67ms p(95)=309.08ms
webvital_time_to_first_byte_good..........: 3 0.969995/s
You may have noticed other metrics in there too. We rely on the web-vitals JS library which exposes a few more metrics, so we've left them in for you to experiment with. You can find more details on all the browser module metrics in our documentation.
You will no longer see browser_first_contentful_paint
in the summary, and instead you can work with webvital_first_contentful_paint
.
setup
and handleSummary
.109
), used on a go panic.browser.close
method is called more than once.browserType.Connect
API, users can now connect to an existing browser instance and execute concurrent tests, which was not possible previously.POST
and PUT
methods for the tracing.instrumentHTTP
. Thanks, @marcin-maciej-seweryn!filepath.Join
on windows with go1.20, which could cause issues for the k6 archive
and k6 cloud
commands.check
that could return incorrect values for some cases with many preallocated VUs.xk6-websockets
updated to v0.2.0 which fixes a lock up of the whole k6.response
object's function from jSON
to json
.page.close
so that it closes the current page and not the whole browser context.Improved the per-VU buffer pool which should greatly reduce memory usage, at a minor expense of higher CPU usage and lower request throughput. In some cases, this change can reduce memory usage up to 50%.
Thanks to @davidpst for the contribution!
Other minor changes in this release:
eventloop.WaitOnRegistered
to execute all scheduled callbacks.isNullish
to be a part of js/common
.sirupsen/logrus
usage.lib.TestPreInitState
in js/common.InitEnvironment
.goja
's generator support.browserContext.SetExtraHTTPHeaders
to work with errors and ErrFatal.Browser.Launch
now transitions to Browser.Connect
when a CDP URL is provided in an environment variable.k6 v0.43.1 is a patch release containing a few bugfixes:
setup()
code when vu.iterationInScenario
from k6/execution
was used.stdout
UI.