I would like to get the total test duration before the test starts and fail if the duration exceeds a specified limit. This is because there is a hard limit on how long client auth tokens are valid for and want to avoid developers creating tests longer than this period.
The only way I can think of now is parsing the options and calculating it but this could be complex (based on different scenario types, waiting and gracefulStop).
I’ve researched all the variables that one would have to consider to create such a function:
â—‹ To parse/calculate, it would need to consider the following variables.
§ Parse time string values e.g. - “30s”, “10m”, “5h”
§ Setup() duration is variable and not included. This should mostly be negligible assuming that this doesn’t take more than a couple of minutes.
§ Taking the “max duration” between multiple scenarios
§ Non-scenario profiles:
â–ˇ Sum(stages.duration)
â–ˇ Duration
§ Scenario profile (incl. startTime + gracefulStop):
â–ˇ shared-iterations - maxDuration
â–ˇ per-vu-iterations - maxDuration
â–ˇ constant-vus - duration
â–ˇ ramping-vus - sum(stages.duration)
â–ˇ constant-arrival-rate - duration
â–ˇ ramping-arrival-rate - sum(stages.duration)
â–ˇ externally-controlled - duration
You have a good summary of exactly what it takes to calculate the max duration of the test run. A couple of minor points though:
Setup() duration is variable and not included. This should mostly be negligible assuming that this doesn’t take more than a couple of minutes.
You can restrict max setup() and teardown() times with the setupTimeout and teardownTimeout options, which will give you an upper bound in your calculations.
§ Non-scenario profiles:
â–ˇ Sum(stages.duration)
â–ˇ Duration
After k6 v0.27.0, every k6 run is running one or more scenarios, each with a specific executor. The top-level duration, iterations and stages options are just shortcuts to running a single-scenario test run with the specific executor that corresponds to the option (see the docs for which it is). So even they have gracefulStop, it’s just the default one of 30s.
So, yeah… calculating the total test duration is a bit complex. We plan to add some helper functions to get this type of execution information inside of the scripts, and I made a note about this use case specifically: Improve execution information in scripts · Issue #1320 · k6io/k6 · GitHub
Until that lands though, you either have to re-implement the Go logic that exists in k6 in JavaScript, or you’d have to write an use an xk6 extension (more info) and then use k6 as a library and call the same functions we do to calculate the max duration internally.