We are currently migrating our own protocol from Gatling 1.x to 2.x. With our protocol, we need to add new Checkers. Having looked a bit at Gatling code, I was wondering what was the recommended way to implement new checkers.
On one hand, in gatling-http, HttpCheck extends Check[R], on the other hand, there is a CheckBase class that also extends Check[R]. Since CheckBase does not seem to be used in Gatling, we were guessing it is here for API purpose… So, we were wondering whether it was best to extends CheckBase or extends directly Check[R]?
Since there are quite lots of stuff, we were wondering someone could give some hints / recipes to implement a new check (steps or which minimal classes to extends, etc.).
Thanks in advance!
Once again, your explanations are clear! Thanks again!
We realize that CheckBase is indeed used and there were some implicit functions defined in the Gatling’s Predef that were converting an ExtractorCheckBuilder into a CheckBuilder and a Check…
So, basically, what we did is:
1/ defining a our own Check (MsgCheck that extends Check[Msg] and acts as a wrapper like it is done for HttpCheck)
2/ defining a MsgCheckBuilder that extends ExtractorCheckBuilder[MsgCheck, Msg, P, T, X]
3/ defining a check factory (similar to the httpFactory)
4/ defining an extractor for our DSL function
5/ defining an expected result / criteria for our DSL function
6/ defining our DSL function to create a new instance of our MsgCheckBuilder
And it works!
Thanks for pointing out the HttpBodyRegexCheckBuilder.scala: it gives a good overview of what needs to be done. Explaining the role of the preparer, extractor, etc. also helped to grasp what and how to implement it.
Many thanks again!
I’m once again impressed by how fast you grasp Gatling code’s logic.
Thanks! But your explanations and Gatling’s code do much to grasp things
By the way, the Error tab in the report is pretty cool and as I start playing with the Check API and Validation, I begin to love the Validation stuff