Hello,
I’m fairly new to gatling (and an SSL novice) so I could be unnecessarily chasing my tail, but I have a situation where some actions need to communicate with a server via HTTPS and some via HTTP. Is it possible to execute certain actions using an HTTPS baseUrl and some using an HTTP baseUrl?
I’m using the csv feeder to create a number of accounts (which require HTTPS). After the accounts are created, I need to use those created accounts to interact with our application using HTTP. I’ve done quite a bit of digging and can’t seem to find much information about this, which makes me think I’m doing something incorrectly. I’m using gatling 1.5.5
Thanks in advance
You won’t be able to use baseURL for both your HTTP and HTTPS requests. I advise you chose the most frequent one for the baseURL, and then you’ll have to use absolute urls for the other scheme.
Still, you can define the host in one single place:
val host = “www.foo.com”
…
baseURL(“http://” + host)
…
exec(request(“httpRelative”).get("/bar"))
.exec(request(“httpsAbsolute”).get("https://+ host + “/baz”))
You know, if there’s one thing about the programming language used for gatling, it’s this sort of thing.
With loadrunner, I can treat the entire request as a single piece of text: Changing headers, protocols, cookies, request parameters and what have you is a simple matter of changing the right line and you’re done. Want to switch to ssl? You just put “https” in the request, or better yet, make a {protocol} parameter and use that instead.
For the reply, pretty much the same thing applies.
With gatling however, everything is hidden behind abstraction layers that quite frankly mostly make life difficult unneccessarily. After all, on the wire all this stuff is just a bunch of text; nothing more.
… and I know that the difference between SSL and non-ssl on the wire is actually really big, but in terms of programming it it really is that simple.
@Floris I’m not sure you got things right. Joseph was asking about baseURL, so I assumed he was aiming for what baseURL provides: keeping things DRY and define your baseURL is one single place so you can change it just once instead of all over the place.
That doesn’t mean that Gatling forces you to use baseURL, you can perfectly only use absolute urls everywhere and edit them the way you want.
Then, I don’t think anyone can claim to be perfect. If some of our APIs/design sucks, the best is to provide feedback as soon as possible so we can change them before the user impact is to big.
@Joseph The following solution is actually more DRY:
val host = “www.foo.com”
val httpBaseURL = “http://”+ host
val httpsBaseURL = “https://”+ host
…
baseURL(httpBaseURL)
…
exec(request(“httpRelative”).get("/bar"))
.exec(request(“httpsAbsolute”).get(httpsBaseURL + “/baz”))
Cheers,
Stéphane
I have a similar challenge - domain sharding, 3rd party sites, multiple test environments , etc
Scripts may be recorded on 1 environment then run against multiple. so built in support to changing the domain easily may be of general use.
I’ll try and add some support for this in the recorder changes. Ie. the recorder can see all the base urls being requested and provide a baseURL plus central/common vals for the other domains.
For Joseph I’m not using 1.5 but presumably the recorder would have produced valid script that would execute the requests with the right scheme http/https, which could provide a starter to script with?
Thanks for the help! That’s a pretty solid solution and I appreciate you getting back to me so quickly
@Alex: I filled a feature request for what you suggested: https://github.com/excilys/gatling/issues/1891
Alright.
The way I work with test environments is that I have a set of linked parameters for protocol, hostname, port, and context path stored in a datafile (CSV file, really.).
What line I pick from that datafile depends on what environment we’re testing, and it’s actually possible to override them on an individual basis using virtual user group specific command line arguments.
The combination of those parameters is what you might call the “base url”, except that this is a little more flexible.
(Note that I don’t always have all of them - sometimes it’s just the hostname, sometimes it’s more, depending on how flexible the script has to be.)
Individual requests use a combination of these parameters + any request specific stuff to create the final url. This means that a request can choose to use a hardcoded protocol, or choose a flexible environment-specific protocol.
Again, all of that depends on how big the need is to decouple the script from the environment under test. Ideally all environments are the same when it comes to this stuff, but in practice there may be large differences.
If I understand this question correctly that kind of decoupling isn’t exactly possible due to gatling assuming that you either want to use a hardcoded baseUrl which applies to protocol, hostname, port, and possible context path at once; OR you want to hand-code it. There is no real in-between mix-and match as I described above.
Hence why I started talking about how the abstraction layers can get in the way of actually doing things properly. 