Add @only decorator to TaskSets

[leonardoraele]

Is your feature request related to a problem? Please describe.

Whenever I want to add a new task to one of the TaskSets, I have to manually set all @task decorators' weights to 0 (or comment them) in order to be able to debug the new task; otherwise I have to wait until the locust randomly pick the new task.

Describe the solution you'd like

Create a @only decorator. This decorator would be attachable to methods in TaskSet classes and would cause that method to be always be called instead of the other tasks. This should be effectively equivalent to setting all existing @task decorators' weights of that class to 0.

e.g.

@task(4)
def my_task(self):
    ...
@task(6)
def my_other_task(self):
    ...
@only
@task(3)
def task_being_tested(self):
    ...

should behave the same as

@task(0)
def my_task(self):
    ...
@task(0)
def my_other_task(self):
    ...
@task(1)
def task_being_tested(self):
    ...

This is inspired by test frameworks that let you run a single test in a suite so that you can debug it.

Describe alternatives you've considered

Manually setting all other @task weights to 0, or commenting them.

Additional context

N/A

[cyberw]

Hi! I think this makes a lot more sense in a functional testing framework, but not in locust.

The workaround doesnt seem very hard, except if you have tons of tasks.

And even if you do have hundreds of tasks you could still do some workaround, like this:

skip_everything_if_zero = 0

@task(4 * skip_everything_if_zero)
def my_task(self):
    ...
@task(6 * skip_everything_if_zero)
def my_other_task(self):
...
@task(1)
def task_being_tested(self):
    ...

(and then set skip_everything_if_zero = 1 when you want to run everything)

[heyman]

I can definitely see the problem, though I'm not sure if an @only decorator would be the best solution. I wonder if it would make sense to be able to make Locust execute a single task by specifying it in the command line arguments (it's not straight forward on how to implement this in a good way though).

[leonardoraele]

Hi! I think this makes a lot more sense in a functional testing framework, but not in locust.

The workaround doesnt seem very hard, except if you have tons of tasks.

And even if you do have hundreds of tasks you could still do some workaround, like this:

skip_everything_if_zero = 0

@task(4 * skip_everything_if_zero)
def my_task(self):
    ...
@task(6 * skip_everything_if_zero)
def my_other_task(self):
...
@task(1)
def task_being_tested(self):
    ...

(and then set skip_everything_if_zero = 1 when you want to run everything)

This seems like unnecessary pollution in the code, that could be avoided by the framework. Why do you think the suggested feature doesn't make sense in locust?

[cyberw]

This seems like unnecessary pollution in the code, that could be avoided by the framework. Why do you think the suggested feature doesn't make sense in locust?

Well... Maybe I was being overly critical. It could make sense, but it would need to be implemented without complicating the framework. To me it seems like a niche use case that risks complicating the framework more than it adds in value. I also agree with @heyman, in that it makes more sense as a command line parameter.

[cyberw]

Actually, having given it some thought I think this makes a lot of sense, particularly if we would start aligning locust to a more "standard" test automation framework (adding things like assertions & other "standard" flags like @only)

[abhijitmamarde]

This is great idea, infact I would suggest to go one step ahead and instead of adding a decorator, to mark to run only that specific task, use markers concept of pytest framework (doc link).

so for the tasks defined as below:

@mark("admin")
@task(3)
def my_task(self):
    ...
@task(2)
def my_other_task(self):
    ...
@task(1)
def task_being_tested(self):
    ...

and say executed like:

$ locust -f locustfile.py -m admin

then only my_task should be executed.

Let me know what you all think about this suggestion.

[leonardoraele]

I like @abhijitmamarde 's suggestion a lot. We could simulate user profiles this way.

[Trouv]

Thought I'd let y'all know that I've started implementing this in my fork, will make a PR sometime soon assuming the maintainers are interested in this feature