8

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?

hauron
  • 4,550
  • 5
  • 35
  • 52

4 Answers4

5

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.
Stephane Landelle
  • 6,990
  • 2
  • 23
  • 29
  • 1
    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. – hauron Sep 02 '14 at 12:02
  • 2
    No, check doesn't break the execution chain by default. Only if you wrap inside a exitBlockOnFail block: http://gatling.io/docs/2.0.0-RC3/general/scenario.html?highlight=exithereiffailed#error-management – Stephane Landelle Sep 02 '14 at 12:08
  • 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? – hauron Sep 02 '14 at 12:15
  • 1
    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. – Stephane Landelle Sep 02 '14 at 12:22
  • 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). – hauron Sep 02 '14 at 13:45
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")))
agrwal
  • 21
  • 1
  • 5
1

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].

Andrew James Ramirez
  • 524
  • 7
  • 16
0

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.

suo
  • 358
  • 3
  • 9