Conditional check - Cheat sheet and usage

I saw the release notes of the 2.2.1 and 2.2.2 versions and something that caught my attention is the new conditional check:

However even though I’ve updated my gatling version I don’t see to find a way to use this feature and it seems to be missing an entry into the cheat sheet:

I thought that I could use this way:


Or some similar way.

What am I missing here?

Thank you!

Indeed, checkIf is missing from the cheat-sheet. We’ll fix, thanks for reporting.
But it’s properly described in the documentation:

And, no, condition can’t be a check. But that’s an interesting idea.

Thank you for your response, looking forward for the cheat sheet.

Would you mind to provide a usage example?

I guess I understood something wrong about the usage.

Thank you very much!

Cheat sheet updated.


For conditional check you need to pass an expression[Boolean].

It’s a function which take a session as argument and return a boolean like this : session => true

For now, you can use it like this. (It shoul’d work, but not tested) :

.checkIf(session => session(“responseStatus”).as[String] == “201”).(jsonPath("…").exists)
.checkIf(session => session(“responseStatus”).as[String] != “201”).(jsonPath(“anotherpath”).exists)

Supplied a check for condition was in my mind, but if I remember well, I couldn’t figure it out.

Thanks for the reply Max,
I’m also struggling with .checkIf()
Here’s a summary of my efforts. I’m kinda desperate for any help!

  1. checkIf() cannot be chained to .check(), it must be passed into the .check() method.


.basicAuth("ldsIdentityTest", DecoderRing.pwd)
.checkIf( session => session("threads").as[Integer] > 1000).jsonPath("$.").exists


Here’s the error I get:

CanaryPage.scala:14: value checkIf is not a member of io.gatling.http.request.builder.HttpRequestBuilder

So, I put checkIf inside a check() method:


.basicAuth(“ldsIdentityTest”, DecoderRing.pwd)
jsonPath("$…[?(‘JVM:Info’)].information.‘Thread Count’").saveAs(“threads”),
checkIf( session => session(“threads”).as[Integer] > 1000).jsonPath("$.").exists


Now I get:

\CanaryPage.scala:16: missing argument list for method checkIf in trait CheckSupport
Unapplied methods are only converted to functions when a function type is expected.
You can make this conversion explicit by writing checkIf _ or checkIf(_)(_)(_) instead of checkIf.

I don’t understand what the compiler is trying to tell me to do. I’m scala ignorant and I have stared at the documentation for hours trying to figure out how to use a checkIf to no avail.

Help me Max Bundy! You’re my only hope :slight_smile:

I’m struggling at the exactly same point that Shayne reported.

The even weirder thing is that my IntelliJ Idea doesn’t even show checkif at the auto-complete feature so I’m clueless about how to use it.

Any more tips?


My mistake, I check, indeed it don’t works, because checkIf is a wrapper and don’t chain.
The signature with an Expression[Boolean] seems not to be visible, you have to use (Response, Session) => Validation[Boolean] instead.

Here is my sample corrected :

import io.gatling.http.response.Response
val foo = exec(http(“my_test”)
.check(checkIf((response: Response, session: Session) => session(“responseStatus”).as[String] == “201”)(jsonPath("…")
.check(checkIf((response: Response, session: Session) => session(“responseStatus”).as[String] != “201”)(jsonPath(“anotherpath”)

The signature with an Expression[Boolean] seems not to be visible

It should be:

Then, I realize compile tests are missing from:

Thank you so much! That’s just what I needed.

So indeed the first form is hard to make compile.
You’d have to help the Scala compiler and provide some types explicitly, case is too complicated for it to infer them.


checkIfResponse, HttpCheck(jsonPath("…")

Far from ideal, I’ll try to find a fix.
If I can’t find one for 2.2.3, I’m afraid we’ll have to remove it.

Maybe 2 names are needed :

a simple checkIf(Expression[Boolean])
and another checkIfWithResponse((Response, Session) => Validation[Boolean])


I’m currently investigating this. We might have to duplicate the whole hierarchy. :frowning:

Or maybe some nested solution as I thought at first:

.checkIf( //this requires the next command to be a “check”
.check(jsonPath("…").exists) //regular check only executed in case of success of the previous one, in a negative case is just bypassed
.check(jsonPath(“anotherpath”).exists) //non conditional regular check

This look simple and very easy to implement.

This feature will probably be completely rebooted in Gatling 3, along with the checks.
And yes, there’s a good chance the first parameter will be a check, just like it’s being doing with the “matching” condition in the future WebSocket API.

By the way, Marcelo, you can avoid the first check which save the response status code, since you have access to the response in the checkIf argument function.