dynamic scenarios

[rlefebvre]

First, nice work with clj-gatling! As I understand it, scenarios are defined as a fixed sequence of steps at the start. How would one go about creating more dynamic scenarios where the next step is determined by the result of a request ? It would be useful if steps could return the next steps to take.

[mhjort]

Hi @rlefebvre

Yes. Currently scenario is a fixed sequence of steps. I like your idea of having more dynamic scenarios. However, I think it would be more clear to separate fixed and dynamic scenarios. Request functions can already return different kind of results (boolean or tuple) and I don't want to make them more complex anymore. My proposal would to keep the fixed scenarios as they are now and introduce new syntax for dynamic scenarios. For example like this:

{:name "My dynamic scenario"
 :step-generator step-generator-fn}

Step generator function would be a function that takes in the context and return a function that should be executed next. So clj-gatling would execute that function after each step has been executed. Each step function then should write something to context that could be used to determine the next step. This is something that step functions can already do.

What do you think?

[mhjort]

...and then when the step generator function returns nil it means that the previous step was the last one.

[rlefebvre]

It seems like it gives complete power to the user to drive the test as he pleases. So that's good for me. Though, it seems necessary to be able to also modify the context from the step-generator. It could return a vector [step-fn context'].

I have done this locally and designed my test as a state machine using ztellman/automat. It works reasonably well but I found that I would also like to sometimes be able to introduce delays. Perhaps the step-generator could return a channel, as the steps themselves do ?

[mhjort]

Makes sense. Would you mind creating a PR from your local changes? That would be really helpful.

[mhjort]

Sorry, changing my mind here. I finally had time to take a detailed look on this. Actually the step generator should not generate just functions. Instead it should generate full steps. This way steps get names that are required for reporting and also delay is supported via normal step sleep-before feature. This means there is no need for step generator to return a channel. So the spec is following:

Step generator is a function that takes current context as an input and it should return a tuple (a vector) like this:

[next-step updated-context]

Where next-step is a just ordinary clj-gatling step which is a map like this:

{:name "Example Step"
  :sleep-before (fn [ctx] 1000) ;Optional
  :request (fn [ctx] do-the-request)}

If step generator returns nil clj-gatling assumes this was the last step of the scenario.

Ideally step generator could return only the step if it does not want to alter the context. However, this is an optional feature that could be implemented later.

@rlefebvre do you want to work on this? If you have something already working it would be nice to merge that in.

[rlefebvre]

Actually, this is how I have implemented it (returning step maps with name and function). I haven't gotten around to trying the channel version yet. I still think it can be useful though, this way you can model wait steps however you wish rather than being forced to use sleep-before.

I will provide a patch with the first approach sometime during next week.

I have since moved on to pure gatling for my immediate needs because of the lack of ramp-up functionality, but its DSL approach makes me want to come back and implement the missing parts in clj-gatling.

[mhjort]

About the channel. I am not against having that. However, I hope it then should support both returning step directly and returning a channel with step.

Regarding ramp-up. There is an issue about it: https://github.com/mhjort/clj-gatling/issues/20 I think it is the most wanted feature and I guess I will have to take a look on that now...

[mhjort]

Released version 0.13.0 which contains support for this.

Thanks @rlefebvre for the PR.

[mhjort]

Already implemented