How to use JS (or even TS) test-script file instead of Yaml

[HugoImaios]

Through the documentation, we can find this :

Artillery test scripts are usually written as YAML, but they can also be written in JavaScript.

Which sounds great 😍 !
After exploring a bit the github packages, we can even find this one which is published on npm as @artilleryio/types and which seems to provides type definitions for artillery config, scenarios, etc. 🎉 (subsidiary question : why is there a DT package (@types/artillery) then ?)

But : how can we run this using artillery ? artillery run seems to be locked onto yaml files, causing YAMLException: end of the stream or a document separator is expected

[bernardobridge]

Hello @HugoImaios 👋,

To use Typescript support, you still write your basic skeleton of a script in YAML. However, in the YAML file you can point to a Typescript processor which contains exported functions, so your actual logic can be written in Typescript or Javascript. How to load the several different types of processors (.js, .mjs or .ts) is explained here.

From there, you would write functions you can then use in your scenarios.

• Here is an example for Playwright.
• For the HTTP engine, if you wanted to write in pure Javascript/Typescript code, you can also call functions within the YAML (maybe a single one in your case), but you'll need to emit your own custom metrics, as you won't have the default HTTP engine metrics emitted then - only the default ones would be emitted.

---

As for your other questions:

we can even find this one which is published on npm as @artilleryio/types and which seems to provides type definitions for artillery config, scenarios, etc.

The name of that package is probably misleading, and we will likely change it soon. At the moment, @artilleryio/types just powers a JSON schema used by our VS Code Extension. The type definitions there are an artifact of a legacy implementation.

subsidiary question : why is there a DT package (@types/artillery) then ?

Those types are not published by the Artillery team, but by an open source contributor. It is mostly quite good, though!

[HugoImaios]

hello @bernardobridge !
Thanks again for the work done on the Typescript and Playwright support, I'm testing it (lol) theses days and it's very nice.
I think I was not clear in my first message. I was not talking about the processors scripts, but really about what is called "test scripts" and which contains the config and scenarios keys. By the doc I quoted, I naively though that this yaml file could be written in js/ts.
I now get that it is not possible (but it's ok, it might not be a huge use-case) :)

[bernardobridge]

Ah I see, sorry if I misunderstood you! I'll update the docs soon to make this a bit more clear, though!

We will probably want to support running from pure JS files at some point, but it's not something we have an ETA for right now. At the moment, as you can run ESM (via .mjs), Typescript (via .ts) and Javascript (.js), it covers the most common use cases with the workaround I described above, as the logic would still be written outside of the YAML, and the YAML would mostly serve as an entrypoint for config.

Do let us know if you run into any issues though!

---

P.S. Glad to know Typescript support is working well for you! 🎉

[HugoImaios]

you're totally right.
If this ever comes back to the table, here is our use-case :
we have playwright configuration (mostly contextOptions and mostly extraHTTPHeaders) logic based on env vars, which we implemented in our playwright.config.ts. For artillery, we currently have to re-implement this in the good old artillery.yaml file, mostly through the environments key

[HugoImaios]

+usecase for TS would be to get auto-completion for artillery config/scenarios

[bernardobridge]

Ahh! That's interesting to know actually, hadn't considered that 🤔.

We'll definitely keep this in mind for further updates to the Playwright engine!

[bernardobridge]

+usecase for TS would be to get auto-completion for artillery config/scenarios

Yes - we are definitely interested in either contributing ourselves to the @types/artillery or publishing our own official ones. It's not something we have gotten to yet, but it will come!

Thanks for all the feedback.

[electrovir]

Just wanted to throw my 2¢ in here @bernardobridge. I recently discovered Artillery and was super interested in it all up until I found out that test cases must be written in yaml. No type safety, no code reuse, white-space as syntax... that's not something they my team can rely on 🙃

(We have to use yaml already for GitHub Actions and that's bad enough as it is.)

[bernardobridge]

Hi @electrovir 👋 . Thanks for the feedback, it's helpful to know that! It does go a bit both ways, as we do have many users who prefer the YAML format (it depends how complex and logic-heavy your tests are, I suppose).

As mentioned above, we did introduce initial Typescript support recently, and you can pretty much write your whole logic in Typescript, and the YAML will just serve as configuration (pointing to the Typescript function needed). Does that not work for your use case?

In the near future we'll be looking to make this more robust, so any feedback helps with that.

[electrovir]

It seems you still have to define all your scenarios in the yaml file though, is that not the case? I've also seen several warnings in the docs about TypeScript support being experimental, which naturally concerns me 😅

[bernardobridge]

@electrovir , the scenario will need to be specified in the YAML config, but not the actual code (you'd point at a function to run it instead). Playwright already works like that. I'll try to add an example soon for HTTP tests soon, but it would look something like this:

scenario.yml

config:
  target: https://example.com
  processor: "./flows.ts"
scenarios:
  - flow:
      - function: "getLoginPage"

flows.ts

//install an http client yourself
const axios = require('axios');

export async function getLoginPage(context, ee) {
    const startTime = Date.now();
    await axios.get(`${context.vars.target}/login`);
    const endTime = Date.now();

    const duration = endTime - startTime;
    ee.emit('histogram', 'http.response_time', duration);
};

You get the overhead of having to emit the metrics you care about yourself, but the custom metrics API allows you to do whatever you need.

Like I said, in the future we will likely add more convenience features around this support, but it's already possible to do most things with it.

---

I've also seen several warnings in the docs about TypeScript support being experimental, which naturally concerns me 😅

That's understandable! It's a relatively new feature, and we need more feedback and understanding of usage patterns before we consider it stable. But we haven't had any major reported issues.

Thanks again for your input!

[electrovir]

Okay, that sounds more promising than I initially interpreted. Do you happen to have any larger example repos off-hand that you could point me to that extensively use TypeScript to run Artillery tests?

[benjaminkay93]

^ i too would find it helpful having a larger example set for TS Artillery tests 🙏