Hi all,
Still going strong with Gatling! I got everything working for a simple application where users basically do the same actions in a random way multiple times.
Eventually I want to test different bigger and more complex applications. I want to make setting up stress tests for these applications as simple as possible. All these applications are made using the same framework and thus have a lot of similar traits.
I was thinking of doing post processing of the recorder output or making the recording process itself more intelligent. For example something that occurs a lot is that: from one request I get a CSRF-token in the JSON response, which I want to extract and pass to the requests that follow. After recording a new scenario for a different application I have to make adaptations to the code again to implement the CSRF-token handling. In my opinion it would be more convenient to do this automatically.
The best idea I can come up with right now is to adjust the *.ssp templates used by the recorder. Thus in a request, instead of putting in the literal CSRF token, I could put the CSRF token variable in.
- add .check(jsonPath("$…csrftoken").saveAs(“csrftoken”)) to store the CSRF token to the specific request
- change “X-Csrf-Token” → “”“1e6794f1e866ec0"”" into “X-Csrf-Token” → “”"${csrftoken}""" in all headers
Is this the way to go or is there some other method that is way smarter?
Thanks in advance.
Roy
Hi,
Overriding the ssp template won’t do the trick: it’s compiled, and we actually drop SSP (both internally in recorder and charts, and for request bodies).
At this time, I don’t see any better trick than:
- replace the header value with the EL expression thanks to a regex
- create a wrapper method “httpWithCsrfToken” (like here) and once again replace original method calls
Maybe I’ll come up with something better…
Cheers,
Stéphane
Hi Stéphane,
Thanks for your swift response. This trick works for the CSRF-token, but there are a lot more similar adaptations I need to make over and over again when recording new scenarios. For instance storing GUIDs from responses where objects are created or retrieved, and passing the GUIDs to other requests where objects are edited or deleted. There are more of these examples.
My point is that I need to make so many adaptations that I want to do them in a generic way. A quick and dirty solution would be to write a script that reads the *.scala file that the recorder produces and do some generic string operations. However since the recorder is already pretty intelligent in understanding the structure of requests and formatting it into Scala code I thought this would be a logical place to add more logic.
What do you think?
Cheers,
Roy
Not sure how we’d determine which customization to apply where… and how…
How to handle CSRF token which appears in header. Please share code.
Thanks,
Santosh Kulkarni