Allowing custom options to passed into tests?

[amandasaurus]

I'm just starting using locust to test our application. Our application can have slugs in the URL that I want to test against. Rather than have to change the task file to put in a new slug to test, I hacked locust to have a -o key value (or --option key value) command line options that will be available in the task as self.options[key].

I've done some work on this branch: https://github.com/rory/locust/tree/custom-options (see the diff here amandasaurus/locust@master...custom-options ). I haven't requested a pull yet because I'm unsure if I'm doing it in a sensible way. I haven't tested this using the master/slave/distributed workflow, since we're not using that yet.

Can you tell me if this is a good feature others might want, and if I'm doing it in a good way?

[Jahaja]

Not sure what your trying to do here. If you just going to use the extra options for url slugs then you should be able to randomly pick a slug from a list in your locustfile or perhaps save a few from the result of a previous request.

Could you give an example of a task that would use the options in the way you intend?

[amandasaurus]

The only example I have is the aforementioned slug example. I know we could just store the slug in the locustfile and use that.

Having command line options is a better separation of code and data. The code to run the test is in the locust file, and that's things that don't change. Where to run it against (and how to run this test) are specified on the command line, with the -H (for host) and -c (concurrent users), so I think it makes sense to be able to control more specifics of the test via the command line.

[Jahaja]

The goal with Locust tests should be to simulate user behavior. With that in mind, the usual way of achieving this is that your Locust visits a page of the website you're testing and saves the slugs that is returned by that request. The subsequent requests will then use those slugs that is saved for the user.

e.g

1. GET /news
2. Parse out the slugs and save it on the Locust (or globally if the slugs don't change depending on user)
3. GET /news/view/[random-saved-slug]

I can't see passing options by the cli as a sustainable solution. The number of concurrent users can be changed by the web interface and the ability to change host could be implemented as well.

[amandasaurus]

In our case, we are a white label B2B site. Our clients will have their own website which has a direct link (incl. slug) to some of our pages. We even theme our pages to look similar to the client's site. The general public (the actual users I want to simuilate), will arrive to that one URL directly.

Obviously some(/many?) people will have the user usage flow you describe, but we have this type of user behaviour.

[heyman]

Hi rory!

I understand your reasoning, and why you would like this feature. I've actually been in a similar need myself. The way I solved it then, was to use environment variables, which I read from the script using os.environ. That turned out pretty well for me. Do you think that could be a good solution for your use case also?

If we would add some kind of options feature, I think one should be able to set these options from the web interface as well. Then comes the question if one should declare the available options somehow? All in all, if it's solvable in the test script code (i.e. using environment variables, or something else), I would prefer to not add the feature to Locust.

And thanks for taking the time to improve on the Locust project, btw :)!

[Jahaja]

Alright, makes sense. Yeah, using an environment variable seems appropriate.

[amandasaurus]

Yeah, I initially thought about using an environment variable, but then thought "bleh, feels hacky, let's patch this!". But, it'll probably do for now.

[mosesliao]

Hi. I am running locustio to simulate many clients stressing a server. I need to be able to pass the GameDataVersion from command line so I do not have to keep edit the variable value on locustfile.py. It is for convenience sake

[crysyn]

The odd thing here is the TaskSet object accepts *args and *kwargs, sets them to self.args and self.kwargs but the calling Locust object does not pass anything into the .run() call.. It looks like this was intended functionality but just never implemented? This would be very handy in my test environment where I need to change the states of the running environment more definitively then is currently possible with Locust (I've already made a few classes to support this gracefully within the environment but as has been said and parroted by others, not having to rewrite a .py file every time I need to change a parameter to it would be very helpful)

PS: Sorry to psudo-revive a dead post but this is the #1 google result at the time for this topic.

[heyman]

@crysyn The args and kwargs are set when scheduling a nested TaskSet using TaskSet.schedule_task() (http://docs.locust.io/en/latest/api.html#locust.core.TaskSet.schedule_task).

Can't you set an environment variable when starting locust like this:

$ env MY_VAR=1 locust -f testfile.py [...]

and then read it in your test script like this

import os

class MyTaskSet(TaskSet):
    def some_task(self):
        if os.environ.get("MY_VAR"):
            ...

You would still need to restart Locust, but at least you don't need to change the python code.

[markfickett]

I'm trying out Locust (very convenient so far!), and have run into this too. My use case is that our app requires a service account token from a file for authentication. I can/will use environment variables, but I like command-line arguments better just for code clarity; env vars tend to be hard to trace / easy to overwrite, since they're effectively globals.

[crysyn]

@markfickett This was a while ago for me but IIRC I ended up writing my own class objects that did what I wanted here so we could hook the tests into jenkins and such to get the appropriate values as well as improve iteration for people developing the scripts.

[DenisKuplyakov]

Env vars is the one of the worst workarounds, because you need to read code of the test to known which env vars you should pass. Arguments for a script with adequate help messages and stuff like default and required will be useful. I think that options parsing should be moved to argparse and some on_setup interface should be exposed to populate parser with additional own parameters.

Or there will be a problems with distributed version in such case? Anyway env vars doesn't look better at such situation.

[aldenpeterson-wf]

@DenerKup we've talked about using yaml config that python reads.

[stixaw]

Is this available
I have 2 different environments and a JWT Token that uses different secrets and ids that i would love to do -e dev and have it read the necessary variables from a config or utility python script.

is there a support thread or group for getting help with LocustIo stuff?

[aldenpeterson-wf]

is there a support thread or group for getting help with LocustIo stuff?

@stixaw check out the Slack link on the readme :) https://github.com/locustio/locust