[Gatling2] implementing a checker

781 views
Skip to first unread message

ctra...@gmail.com

unread,
Jul 10, 2013, 3:45:03 AM7/10/13
to gat...@googlegroups.com
Hi all,
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!



Stéphane Landelle

unread,
Jul 10, 2013, 8:39:44 AM7/10/13
to gat...@googlegroups.com
Hi,


We are currently migrating our own protocol from Gatling 1.x to 2.x.
Cool!

 
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.

It depends on whether you want to reuse our DSL (regex.find.exists.saveAs stuff) or not. You can write your own DSL if you want, the important thing is that you end up telling the DataWriters the requests that succeed and the ones that fail, like here:
 
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...
 
It is used of course! ;)
HttpCheck is implemented as a wrapper of a CheckBase (composition rather than extension) and delegates the check invocation:
 
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.).

I tried to really simplify the Check API and built-in implementation in Gatling 2, and we'll of course document this.

CheckBase is composed of:
  • a preparer that can parse the response, for example, building the String representation of an HTTP response body byte array
  • an extractor, for example regex
  • an extractorCriterion, for example, the value of the regex
  • a matcher, for example, is
  • an expectedExpression, the expected value the actual extracted value is matched against
  • saveAs

In Gatling HTTP, Check are built from CheckBuilders, that are actually the DSL for the underlying Check API.

Note that the builders' hierarchy has 2 branches: single and multiple, depending on if what you're checking can have multiple occurrences (ex: a regex on an HTTP response body) or not (ex: the status code).

Am I being clear?

Cheers,

Stéphane
 

ctranxuan ctranxuan

unread,
Jul 10, 2013, 10:32:22 AM7/10/13
to gat...@googlegroups.com
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!




2013/7/10 Stéphane Landelle <slan...@excilys.com>

--
You received this message because you are subscribed to the Google Groups "Gatling User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gatling+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Stéphane Landelle

unread,
Jul 10, 2013, 10:41:16 AM7/10/13
to gat...@googlegroups.com
Very cool!
I'm once again impressed by how fast you grasp Gatling code's logic.


2013/7/10 ctranxuan ctranxuan <ctra...@gmail.com>

ctranxuan ctranxuan

unread,
Jul 10, 2013, 11:48:42 AM7/10/13
to gat...@googlegroups.com
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 :)

Thanks again!
Reply all
Reply to author
Forward
0 new messages