share connection between several scenarios

Gatling (Open-Source)
1

Hi everybody,

I am working with Gatling 2 to test a website’s electronic cart.
You can do your shopping in live…
We did a persistant cart, for example: an anonymous client is visiting the website, then he adds some articles. He closes the browser and when he re-open it, he finds the same cart saved in the session…

My job is to test this session. I would like to use the SAME user to recover the session saved.

Here that I would like :

val httpConf = httpConfig.baseURL(“http://previewfr.dev.intuiko.lild01.pictime.fr”)

setUp(
scn1.USER.protocolConfig(httpConf),
scn2.USER.protocolConfig(httpConf)
)

val scn1 = {
scenario(“consult random products, update quantity in cart”)
.repeat(5) {
feed(randomSkuProduct)
.exec(
http(“view a product”)
.get("/StarterEcommerce/catalogEntry.html")
.queryParam(“langId”, “1”)
.queryParam(“ceId”, “${parentid}”)
.check(status.is(200)))
.pause(200 milliseconds)
}

.exec(
http(“add product”)
.get("/StarterEcommerce/cart.html")
.queryParam(“action”, “add”)
.queryParam(“skuId”, “540”)
.queryParam(“quantity”, “1”)
.queryParam(“parentId”, “148”)
.queryParam(“modal”, “true”)
.queryParam("_", “1379948801309”)
.check(status.is(200)))
.pause(2000 milliseconds)

.feed(randomSkuProduct)
.exec(
http(“update quantity”)
.get("/StarterEcommerce/cart.html")
.queryParam(“action”, “updateQuantity”)
.queryParam(“skuId”, “${skuid}”)
.queryParam(“quantity”, “2”)
.check(status.is(200)))
.pause(100 milliseconds)

.exec(
http(“get cart”)
.get("/StarterEcommerce/cart.html")
.check(status.is(200))
.check(header(“Set-Cookie”).saveAs(“cart”)))

.exec(session => {

import com.excilys.ebi.gatling.http.cookie._
import java.net.URI

val cart = session.getAttribute(“cart”)
println("1st connection. Cart = " + cart.toString); session
})
}

val scn2 = {
scenario(“second connection”)
.exec(
http(“get cart”)
.get("/StarterEcommerce/cart.html")
.check(status.is(200))
.check(header(“Set-Cookie”).saveAs(“cart”)))

.exec(session => {
import com.excilys.ebi.gatling.http.cookie._
import java.net.URI

val ck = session.getAttribute(“cart”)
println("2nd connection. Cart = "+ck.toString); session
})
}

Just, i would like to simulate a closing of the browser.

I tried this shareConnections but it doesn’t work…

Please help :frowning:

Thanks !

ps: sorry for my english, i am french :slight_smile:

2

Sorry I am working with Gatling 1.5.2 :slight_smile:

3

Hi,

(always funny when two French people talk together in English)

We don’t support this use case out of the box, (IMHO, more of a functional test than a stress test).
We could, though, but only for Gatling 2.

Let me explain.

Cookies fall into 2 categories:

  • session cookies that get flushed once the browser is closed
  • persistence cookies that get stored on the computer file system until they explicitly expire

Your persistent cart mechanism is implemented on top of the latter.

Implementing browser closing means removing session cookies from Gatling’s user session.

Then, could you upgrade to 1.5.3-SNAPSHOT? http://repository-gatling.forge.cloudbees.com/snapshot/com/excilys/ebi/gatling/highcharts/gatling-charts-highcharts/1.5.3-SNAPSHOT/gatling-charts-highcharts-1.5.3-20130927.163503-2-bundle.zip

Cookie code in 1.5.2 is not an open API and things are much much easier now.

Here’s the code you need (honestly haven’t tried it):

def closeBrowser(session: Session) = {
import com.excilys.ebi.gatling.http.cookie.CookieHandling._
import com.excilys.ebi.gatling.http.cookie.CookieJar

val cookieJar = session.getTypedAttributeCookieJar
val cookieJarWithoutSessionCookies = CookieJar(cookieJar.store.mapValues(.filter(.getMaxAge != -1)))

session.setAttribute(COOKIES_CONTEXT_KEY, cookieJarWithoutSessionCookies)
}

then, in your scenario:

.exec(closeBrowser(_))

Cheers,

Stéphane

4

Hi Stéphane,

Thank you to reply so fast :slight_smile:

Hum, if I upgrate to 1.5.3, i have to change all my classes…
And i took many time to do this project…

There is no other solution ? really ?
It’s embarrassing… :S

Thanks a lot ! :slight_smile:

5

For the record: the compilation errors were just a matter of forcing re-compilation.