HttpRequetWithParamsBuilder - params member val

Gatling (Open-Source)
1

Anyone object to turning the params member in HttpRequestWithParamsBuilder into a val?

This would allow me to do some trickery in my IntegrationUtils.

Basically, I accept a list of HttpRequestWithParamsBuilder. And I want to rename each of those with their (index + 1) number as a prefix.

I had tried to copy doing something like:

type Step = HttpRequestWithParamsBuilder

def renameStep(astep: (Step, Int)) = {

val (s, num) = (astep._1, astep._2+1)

val newName = numberName(num, s.commonAttributes.requestName)

val newAttrs = s.commonAttributes.copy(requestName = newName)

new Step(newAttrs, s.httpAttributes, newAttrs.queryParams)

}

But that’s not really doing what I think it should be doing (besides which, tests begin to fail).

I think it’d be more appropriate to do something like:

type Step = HttpRequestWithParamsBuilder

def numberName(num: Int, name: Expression[String]): Expression[String] = (s: Session) => name(s) match {
case Success(n) => “% 3d. %s”.format(num, n)
case Failure(f) => “% 3d. %s”.format(num, f)
}

def renameStep(astep: (Step, Int)) = {

val (s, num) = (astep._1, astep._2+1)
val newName = numberName(num, s.commonAttributes.requestName)
val newAttrs = s.commonAttributes.copy(requestName = newName)
new Step(newAttrs, s.httpAttributes, s.params)
}

Thoughts? A better way of doing things? Want a pull request? Add the 4 chars yourself :wink: ?

Thanks,

–Spencer

2

Can’t say I’m fond of this.

This has changed countless times and might change in the future as well. HttpRequestWithParamsBuilder is an implementation detail.

Let’s talk about this tomorrow.

3

I can appreciate that.

I figured that this numbering feature wasn’t really something you’d want to pull into gatling properly - how would you number different execs inside a randomSwitch, for example?*

All the same, the numbering feature would be very useful as it helps give a sense of where in the simulation any failures occur. And given the way that requests can move around during the development and maintenance of tests, numbering manually is very taxing.

One thing I do for integration testing is run the test with the maven gatling plugin. I pipe the output through a grep that selects anything not KO=- or KO=0. I then pipe those results through a sort and uniq. So, at the end, I get all my failures grouped by scenario name but not necessarily by the order they occur in the scenario. Having this numbering feature would allow my results to be grouped by scenario and in the order that they failed.

So, I hope you can see how the feature has value. And, even if we can’t do anything for explicit support in the gatling code, a proposed implementation solution or maybe an exposed hook to help me get it done for my code would be appreciated.

And I’m well aware that HttpRequestWtihParamsBuilder has changed. I’ve used it predecessors and was very pleased when I saw them migrated to this current implementation - it’s much easier to deal with! And I can understand and accept that things will change in the future - I’m happy to accept that burden. Hopefully, though, I’ll be able to sit steady on the next release for a while :slight_smile:

Thanks for taking the time to think through it with me!

–Spencer

  • Actually, now that I think about it, I think you’d label them as “##aa” where “##” is where in the sequence the exec is (1, 2, 3, or … n) and “aa” is a letter representing the chosen random selection in the order that it appears in the list(a, b, c, or … zzz))
4

If I get it right, what you actually need is to be able to relate failures and the scenario step where they occurred. Right?

I think we can improve this in 2M5: https://github.com/excilys/gatling/issues/1769

5

Pretty much, yes.

When you have a bunch of scenarios running in parallel and a handful of failures, it can be difficult figuring out where in the scenarios the bad request is.

I’ll type up a few more notes when I’m back at my desk.