Scopes in JMeter

Scopes in JMeter

As you all know, JMeter runs performance test scripts on Test Plans. Those test plans are structured as a parent-child hierarchy relation. You can add as many children as possible to a parent object. That brings us the scoping issue. In this article, we will present an explanation of JMeter’s scoping rules. When speaking of the scope of an element, we should understand which element has access to which another element. Basically scoping works as a parent-child hierarchy.

When you execute the test, samplers are executed according to their location on Test Plan tree but some elements like assertions and timers don’t work that way. They affect all elements that exist on the same level. The main component who creates those hierarchical levels is Controllers. Whenever you add a new controller, you create a new scope.

Let’s take a look at this in different examples.

Timer Scoping Example 1

Let’s create a Thread Group and add two HTTP samplers under it. Then we add a Timer on the same level and configure its delay to 1000ms. As the constant timer is on the same level as those HTTP Samplers, it will affect all of them and HTTP sampler will pause 1000ms after every request. There might be some millisecond difference but you can ignore those.

Timers are always applied to all the elements from the same scope. It doesn’t matter where that timer is situated on the test plan. It is important to know that this rule is valid regardless of the location of the assertion element. It will always be applied for all the elements within its scope.

Timer Scoping Example 2

Now, let’s add a Loop Controller under the Thread Group. Under this controller, we add an HTTP sampler and a Constant Timer and set its value to 1000ms. Now those newly added JMeter components are child elements compared to previously added elements.

When you run those tests, you will notice that HTTP Sampler under this loop controller will wait for 2 seconds. So we can conclude that parent elements affect its child elements.

Assertion Scoping Example

Same scoping rules apply to Assertions, too. Any assertion added to a test plan will affect all the element in the same level and its children. If a request has an assertion as a child, then this assertion will only affect that specific request has an assertion.

You also notice that ‘Response Assertion 1’’ and ‘Response Assertion “2”’ are situated in different parts of the script but they are applied to HTTP sampler under the Loop Controller. But ‘Response Assertion 1’ applies also to all the other requests.

Note that assertions are always executed after any request but timers are executed before any request. That’s the one and the only difference in execution logic.

Scoping Exceptions:

HTTP Cookies and HTTP Header are an example of that scoping exception. While timers and assertions are merged together and applied to a request, Cookies and Headers are preserved. There’s no overriding or merging.

Check out Loadium blog for more content about load testing!