Moving from k6 and JMeter
You do not need to rewrite your k6 scripts and JMeter plans. Tests → Open file turns a k6 script (.js, .ts) or a JMeter plan (.jmx) into a Spitfire test and opens it in the editor; you review it and save. The file is only read, never run. Everything without an equivalent is listed in a report with its line: nothing is dropped silently.
How
- On the Tests page, press Open file and pick the file (up to 4 MB).
- The report above the editor says what was converted and how: not converted (missing from the test), check (converted approximately), note (how it was converted).
- Review the steps, thresholds and variables; Try sends one iteration of the selected scenario and shows every request and response. Then save.
A whole suite at once
For hundreds of tests you do not open files one by one. Select several in Open file: the bulk import page converts, validates and lists each with its report; fix names and save the ones you pick with one button. The ones that need fixing open in the editor. For a whole folder, the command line:
spitfire convert ./jmeter-tests ./k6 -o spitfire-tests/ -r report.csvOne test file per script is written and validated; scripts with no convertible request (only gRPC, WebSocket…) are counted separately, and every report line goes to the CSV (file, test, line, level, message). Load the resulting files with Open file, in bulk again 0.5.16+.
From a k6 script
| k6 | Spitfire |
|---|---|
options.vus / duration / stages | Load model: constant or ramping VUs |
options.scenarios | One scenario each; executor, startTime and every k6 executor under the same name |
options.thresholds | Thresholds, same syntax (p(95)<500, abortOnFail, tags as step/scenario) |
http.get / post / put / patch / del / request | HTTP step: method, URL, headers, body (JSON or form) |
check(res, {...}) | Checks: status, text in the body, JSONPath, duration |
res.json('a.b') · JSON.parse(res.body) · res.headers['X'] | Extraction from the response (JSONPath or header); {{name}} in later requests |
sleep(n) · randomIntBetween | Think time (fixed or a range) |
group(name, fn) | The group name prefixes the step names |
__ENV.BASE || 'https://…' | A variable with its default |
__VU · __ITER | {{__VU}} · {{__ITER}} |
setup() | Its returned values become variables; its requests run once per VU as the first steps (once per test in k6) |
Threshold expressions and CI exit codes (99 thresholds failed, 97 a threshold aborted the run) are the same as k6's: the gate in your pipeline stays, only the command becomes spitfire cloud run "Test name".
From a JMeter plan
| JMeter | Spitfire |
|---|---|
Thread Group | Scenario: constant or ramping (ramp-up) VUs with a duration, iterations per VU with a loop count |
HTTP Request | HTTP step: method, URL, parameters, body |
HTTP Request Defaults · Header Manager | Base address and headers on every request below |
Response · Duration · JSON Assertion | Checks |
JSON Extractor · Regular Expression Extractor | Extraction from the response |
Constant · Uniform Random Timer | Think time |
User Defined Variables · ${__P(x,default)} | Variables with their defaults |
${__Random} · ${__UUID} · ${__time} · ${__threadNum} | Spitfire template functions |
Transaction · Simple Controller | Flattened; its name prefixes the steps |
Disabled elements are left out. A Thread Group with both a duration and a loop count is converted by duration; one that loops forever with no duration is set to 10 minutes; the report says both.
What is not converted
These are listed in the report with their line; you set up the Spitfire equivalent by hand before saving:
- Loops and conditions (
for,if; If/Loop/While Controller): Spitfire runs the steps in order, every iteration is the whole flow. - Data files (
SharedArray,open(), CSV Data Set): upload the CSV under Data files and bind it to the test; columns become{{users.email}}. - Non-HTTP requests (k6 WebSocket/gRPC, JMeter JDBC/JMS…): Spitfire supports most of these built in (WebSocket, gRPC, SQL, Kafka, MQTT, AMQP, Redis, MongoDB); add the step in the editor.
- Custom metrics and free-form code (Trend/Counter, JSR223/BeanShell): no equivalent; per-step timings, checks and thresholds cover most cases.
- JMeter plugins and listeners that write results to files: results are on the run page, reports in PDF/HTML.
Once you have moved
Once the test is in Spitfire, you get these without writing code: splitting a run across locations by percent, environments (the same test against staging and production, with their variable and connection differences), load scale from the Run dialog, the breaking point (stepped load finds the rate where the system misses the criteria), findings on a finished run with its own numbers, scheduled runs, alerts on a regression against the baseline, and shareable PDF reports.
Installing is one command: installation guide. The tools side by side: comparison.
Open file came with Spitfire 0.5.14, bulk import with 0.5.16. If you see a common pattern it cannot convert, tell us and we will add it to the converter.