I’m trying to write a test where I send some randomly generated data over HTTP along with a hash of the contents, getByteArrayBody works perfectly for generating the data but I am having some trouble with the hash being passed back. I know sessions are immutable so passing data back through that doesn’t seem possible - does anyone have any other ideas?
Some more info on my requirements:
Message 1 has no hash
Message 2 has a hash of message 1
Message 3 has a hash of message 1 + 2
etc.
The hash generation mechanism isn’t a problem, the root of the issue is that I cant store the state (last hash) or pass back the current one to the scenario
Currently 1.4.1 but if I add to the session how do I get that session back to scenario, for example:
val scn = …
byteArrayBody(session => getByteArrayBody(session))
.header(“hash” → “${computedHash}”
…
val getByteArrayBody = (session: Session){
val content = //generate content
val digest = //generate digest
val newSession : Session = session.setAttribute(“computedHash”, digest)
content
}
This works fine inside the getByteArrayBody but once I get back into the scenario that new session is lost and I don’t get a value for ${computedHash}. I figure I could just make a java holder class and pass an empty instance of it into getByteArrayBody then set the internal value to the digest but this is kind of ugly and I’d prefer to use the session if possible - maybe I’m missing something?
I guess that would work but I’d like to try to scale up the test to larger and larger message sizes and I dont like the idea of leaving everything in the session but I guess I could remove the last messages content before sending the next message.
I’ll give this a shot some stage today and see if it works out
I guess that would work but I'd like to try to scale up the test to larger
and larger message sizes and I dont like the idea of leaving everything in
the session but I guess I could remove the last messages content before
sending the next message.
I'll give this a shot some stage today and see if it works out
Yep, that's what I'm suggesting. I agree that it might decrease performance
a bit as messages will be hanging around longer, but I don't see any other
solution than storing the message and the hash altogether in the session.
Beware that you want the hash of the previous message, so you have to
compute it first before replacing the message.