jsonPath returns a MultipleFindCheckBuilder
.find and .transform return a ValidatorCheckBuilder
None of these traits implement a .saveAs method which is defined on a CheckBuilder trait. Even though the two above traits are named after a “CheckBuilder” they don’t actually extend that trait in the code.
So how come does the compiler not complain? It is beyond me.
In the case where no verifying step is defined, a exists is added implicitly.
.exists actually returns a CheckBuilder object which does implement .saveAs, that is nice. Yes, but how does the compiler know that it should be “automatically” adding .exists here?
Do you want to learn how those things work to become a Scala developer? As a Gatling user, this is an implementation detail.
Also, are you aware that Gatling 3.7 has a Java DSL too? It would probably be easier to understand (oh the boilerplate to implement it compared to Scala…).
Also, are you aware that Gatling 3.7 has a Java DSL too? It would probably be easier to understand (oh the boilerplate to implement it compared to Scala…)
I found out this week and I told the Tech Leads in my project about it. Java DSL is definitely a great selling point.
We are however currently using Gatling 3.6 and if and when we are going to upgrade to 3.7 remains to be seen.
It might also be that in this particular project we are stuck with Scala.
We have actually created a layer on top of Gatling that allows people with very little Gatling and Scala knowledge to create simple tests.
This works out pretty well unless it doesn’t :-). Until this week our tests only needed to do very simple and always mandatory extractions.
Now I am extending our wrappers to also allow for optional checks and this is how I started looking at the relevant check APIs.
So this is the context of my question. I think I will be able to do what I need even not knowing what happens under the hood.
Being new to Scala I thought I could ask about the observed “magic” out of personal interest.
Being new to Scala I thought I could ask about the observed “magic” out of personal interest.
This “magic” comes basically from implicit conversion.
When the compiler does not find direct implementation (either an attribute or a method) in the type of the variable, it checks if there are implicit conversions in the scope that can be applied to the current variable that satisfies the requested name (attribute or method).
Terminology:
conversion: a function that takes one parameter (with a defined type) and results in another type. sample: Integer.parseInt(str: String): Int (conversion from String to Int)
implicit: a keyword and an “authorization” to the compiler to apply this object (value or method) when direct calls are not available
To put such implicit conversions in scope, we required you to import io.gatling.core.Predef._, so, everything in Predef (and its ancestor) is imported in scope.
For the specific case you mention:
ValidatorCheckBuilder implements CheckBuilder.Validate (a Validate trait declared in CheckBuilder object)
As you saw, they don’t define a saveAs method
The compiler look in implicit conversions available in scope
Among other things: io.gatling.core.Predef extends CoreDsl that itself extends CheckSupport
You imported everything in Predef
The compiler can apply the validate2Final implicit conversion to obtain a CheckBuilder.Final that implements the saveAs method
Hi Sébastien,
Wow, your answer is way more detailed and way more precise than what I actually hoped for, thank you for that.
I would normally search for the articles on the ‘implicit conversion’ myself, but that is just difficult not knowing that such a thing exists.
Now I know why some code in my project compiles (which gives me a nice warm feeling inside)!