How to fail a Gatling test from within "exec"?

Question

A Gatling scenario with an exec chain. After a request, returned data is saved. Later it's processed and depending on the processing result, it should either fail or pass the test.

This seems like the simplest possible scenario, yet I can't find any reliable info how to fail a test from within an exec block. assert breaks the scenario and seemingly Gatling (as in: the exception throw doesn't just fail the test).

Example:

// The scenario consists of a single test with two exec creating the execChain
val scn = scenario("MyAwesomeScenario").exec(reportableTest(

     // Send the request
     exec(http("127.0.0.1/Request").get(requestUrl).check(status.is(200)).check(bodyString.saveAs("MyData")

     // Process the data
    .exec(session => { 
         assert(processData(session.attributes("MyData")) == true, "Invalid data");
    })
))

Above the scenario somewhere along the line "guardian failed, shutting down system".

Now this seems a useful, often-used thing to do - I'm possibly missing something simple. How to do it?

Preempt

Answer 1

You have to abide by Gatling APIs.

1. With checks, you don't "fail" the test, but the request. If you're looking for failing the whole test, you should have a look at the Assertions API and the Jenkins plugin.
2. You can only perform a Check at the request site, not later. One of the very good reasons is that if you store the bodyString in the Sessions like you're doing, you'll end using a lot of memory and maybe crashing (still referenced, so not garbage collectable). You have to perform your processData in the check, typically in the transform optional step.

Erv

Thank you for the answer. I'll look into the Assertions API. About the check: afaik check would break the execution chain, stopping further data cleanup/log from commencing, and I'd like to avoid losing that (I've read some of your conversation regarding implementing "slow fail"). Also the memory is of no concern in this particular test: we're using Gatling both for functional "yes/no" and performance testing. – Preempt

No, check doesn't break the execution chain by default. Only if you wrap inside a exitBlockOnFail block: gatling.io/docs/2.0.0-RC3/general/… – Erv

Sorry, I thought to have an older version of Gatling installed. Assertions seem in fact perfect. Can I ask you whether is it possible assert session data from the scn(...).assertions(...) level? – Preempt

No, backing stats are only computed globally, so assertions is only available at setUp level atm. We plan on refactoring the assertions engine in 2.1, so you could open a feature request. – Erv

As this was (seemingly) impossible to do, I've reverted to failure caused by request checking (as suggested). Noteworthy - it simplified the flow greatly (although reduced code flexibility). – Preempt

Answer 2

were you looking for something like

  .exec(http("getRequest")
    .get("/request/123")
    .headers(headers)
    .check(status.is(200))
    .check(jsonPath("$.request_id").is("123")))

Period

Answer 3

Since the edit queue is already full.

This is already resolved in the new version of Gatling. Release 3.4.0

They added

exitHereIf

exitHereIf("${myBoolean}")
exitHereIf(session => true)

Make the user exit the scenario from this point if the condition holds. Condition parameter is an Expression[Boolean].

Eyeful

Answer 4

I implemented something using exitHereIfFailed that sounds like exactly what you were trying to accomplish. I normally use this after a virtual user attempts to sign in.

exitHereIfFailed is used this way

val scn = scenario("MyAwesomeScenario")
.exec(http("Get data from endpoint 1")
  .get(request1Url)
  .check(status.is(200))
  .check(bodyString.saveAs("MyData"))
  .check(processData(session.attributes("MyData")).is(true)))
.exitHereIfFailed // If we weren't able to get the data, don't continue
.exec(http("Send the data to endpoint 2")
  .post(request2Url)
  .body(StringBody("${MyData}"))

This scenario will abort gracefully at exitHereIfFailed if any of the checks prior to exitHereIfFailed have failed.

Spectrum