No, i’m not going to write about ecology today ?.


Lately, I was asked to do a consultancy job and look at some JMeter performance testing scripts. One of the issues discussed, was how to ‘manipulate’ the results or to be more exact, how to turn a failed response into a successful, green one.


As for changing the outcome of samplers, definitely it’s not something that should be done and a process that I’m not keen on doing. However, let me tell you the context first.

Bloody red results

The story is that substantial share of the application under test’s guests are first time visitors. Additionally, it has a very rich content, so there is huge network traffic connected with not-cached resources like photos, fonts etc. And it’s crucial for the customer to simulate this traffic as accurately as possible.

As for JMeter, it provides out of the box a setting to download this embedded resources, but, well… it is not perfect.


So it might happen that the JMeter parser:
    • could set a correctly downloaded resource as failed, because parsing process of the file has crashed,


  • or it does not recognize that some resources should be automatically downloaded (e.g. because they are linked from javascript code).
    You will need to add such requests manually to the script and bundle them cleverly in a single transaction with the parent call for the html.
    This entails maintaining lots of resource requests by yourself, which ends up in a big pain since the content for the application changes very often.

For each page you download dozens of photos etc. Imagine that you get back a single failed response (e.g. 404) for just one of them.

What happens then?

A whole transaction is marked as failed and that really does a mess out of summary results.


Here’s where a need for ‘manipulation’ of the results arises. Basically, if you get a failure originating in the embedded resources similar to the cases described above, you can just tell JMeter to omit marking the responses in red.

So how to do it? As usual in JMeter, you can deal with this stuff in couple of ways.


Going green with response assertion

The simplest way to handle such issues is to use a good old response assertion.


Just select if you want to apply it to main sample, child samples or both. Check the ‘ignore status’ checkbox as well. And you’re done.



Just remember to add it to correct scope of samplers, as you certainly don’t want to omit more samplers status than needed.

Turn it green differently

Earlier in the post I mentioned, that most often there are multiple ways of making things happen in JMeter.

For instance, once requests fail annoyingly for some embedded resource(s), you could always set a property in file:




And just enjoy the silence…Ahem, I mean greenness.


To cope with the latter case (embedded resources added manually as requests) you need to do some simple coding. Let’s use JMeter’s SampleResult API to check if the request failed and set it to successful in that case.


if (prev.isSuccessful() == false) {


‘prev’, used in the code, is an object of SampleResult class. Hence we can utilize all the methods specified in the API documentation to get info about result of a request and potentially change some portions of it.


Next, add the above code to a PostProcessor (preferably JSR223), which should be scoped so it applies to all samplers that we want to turn green in case of failure:



 As you can see above, PostProcessor did its job and turned the result to green. In this case, response code and other details of the response stay untouched, it’s just the successful/failure flag that was modified.


Another result modification example

SampleResult API can also be helpful in other situations. I will give you a rather peculiar example.


Late in 2016 I did a review of online JMeter services, among them a RedLine13 platform.


When I ran my test script it looked like the service had erroneously treated responses with some http response codes (e.g. 304) as failures.


That led to some crazy statistics from test runs:


It surely doesn’t look pretty in the center of your test report…


Hopefully RedLine13 service has already fixed it, because apart from this, it seemed like a quite interesting cloud service for JMeter.


How to work around this thing? It looked to me that the service was checking if the request ended up with response code 200 and marked the sample as failed otherwise.
 The fix is easy, use SampleResult API to set response code to 200, when it is originally returned as 304:


if (prev.getResponseCode().equals("304")) {