Allowing custom options to passed into tests?

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 https://github.com/rory/locust/compare/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?

[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.

[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.