[gatling 2] master - saveAs not working?

Gatling (Open-Source)
1

Hi there,

Looks like the saveAs method is not saving stuff in the session any more, at least not for regexes.

Anyone else seen this behaviour?

Cheers,

Stefan

2

Hi Stefan,

This should be fixed, now.
Will get things stable next week.

Cheers,

Stéphane

3

Hi again,

Did you mean that
1 - saveAs is currently not working and will be fixed soon
2 - saveAs is ok in master

Cheers

Stefan

4

Hi Stefan,

2: fixed in master.

5

yes indeed it does.

The issue we were having was that we tried dumping the session by making a second regex fail. In that case, the saveAs doesn’t work it seems

.check(regex(“aaaa(\d*?)aaaaa”).saveAs(“id”))
.check(regex(“make it fail - this doesnt match”))

6

BTW, thanks for you quick reply.

Stefan

7

The issue we were having was that we tried dumping the session by making a
second regex fail. In that case, the saveAs doesn't work it seems

        .check(regex("aaaa(\\d*?)aaaaa").saveAs("id"))
        .check(regex("make it fail - this doesnt match"))

It never has: if one check fails, none of them can save.
That's maybe something we could change, but I'd like some feedback from the
community.
IMHO, a failing check means something went wrong. If something can be
missing, use a whatever clause.

Sorry for the bug in the first place: I developed like crazy in order to
show some cool stuff at Scala.Io (and ended up not finishing).
Thanks for reporting,

Cheers,

Stéphane

8

You can’t really assume that wishing to report a transaction failure has any bearing on the desire to save data.

Coming up with hypothetical scenarios where such a relation does not exist isn’t that hard. Situations where you have persistent session data that is required on the next user action even in error paths, situations where you wish to capture the precise error data for post test analysis are actually common, and given the sheer variety of tools and protocols involved you really don’t want to preclude the user from writing things you did not anticipate up front.

Maybe the last bit is the real point. Flexibility is a virtue in a tool like this. Don’t restrict that without good reason.

9

IMHO, there’s pros and cons on both strategies (failing fast or trying as hard as possible).

Until now, the general strategy in Gatling has been the first one, and we haven’t received any complain :slight_smile:

For example, checks are sorted (basically status, then headers, then body). If a status check fails, is there really a point trying to check the body (hence trying to extract something there)?

10

You are thinking about this from a programmers perspective, not a testers. Yes, in programming, failing fast and as efficiently as possible is the right thing to do.

But in testing, failing is the most important thing your script can do. Finding problems and reporting on them is what you use the tool for in the first place. Failure is not a nuisance to be disposed of as quickly as possible: Failure is a success, and the moment that you wish to capture in as much gory detail as possible.
That is why we have a standing policy to run tests with the logging set to `log all errors and up to 100kb of everything that occurred up to that point.’
We don’t capture successes: we capture failure.

Do you now understand where I am coming from?