Same issue here. Using "nothingFor" is odd to use.
What i think we are all asking is to be able to use the same Gatling API as if it were a plain HTTP client.
To explain, currently i am using the very asynchttpclient that Gatling was using in version 2 in order to initialize a specific scenario.
But asynchttpclient's API is not as good as Gatling's. With the Gatling's DSL i can create a scenario with multiple steps, pass variables across with the steps (using session) and eventually perhaps in my last step, gather all needed data and save to a file. And i could do that for as many users as i wished.
One example is obtaining an initialization file filled with auth tokens, which may be complicated (more than one step) to obtain for a given user or number of users. Those tokens are ephemeral, so they have to be re-generated at every run or so. Once the initialization file is saved (no stats needed up to this point), then the very scenario I really wanted to load-test is run, and the stats are generated just for that.
I think what Stephane is saying (is he?) is that this issue should be dealt with by separate logic and scripts responsible for initializing (in the case of the before hook), or by docker containers that can then be easily disposed of, thus relieving yourself from the difficult task of reinstating (after hook) previous db state or such.
But what i found in practice is that it is much easier to use Gatling's DSL to instead write those initialization scripts, unless of course initialization data is huge, convoluted and database heavy.
Unsure if we are getting outside of Gatling's DSL responsibilities, but thought i explained a practical use case.
Without this, it is harder to create smaller scenarios exercising only portions of more convoluted ones.
Max