--- title: Simple Way to Create Complex JMeter Scenarios url: https://blog.octoperf.com/simple-way-to-create-complex-jmeter-scenarios/ date: '2020-03-16' authors: - sjenkins categories: - JMeter tags: - JMeter - Controller - Plugins - Sampler - Thread Group - Runtime - Performance Testing - Dummy - Groovy description: Simple way for creating complex business scenarios in JMeter using Groovy scripts, the JMeter Switch Controller, and a JSR223 Sampler. --- # Simple Way to Create Complex JMeter Scenarios Creating complex performance testing scenarios in JMeter can be a **complicated but necessary problem** you will encounter as you build tests to mirror real user behaviour in your testing. There are many add-ins that can support you in the creation of these scenarios. Which is good if they do what you want them to do. But if you want the flexibility to build tests without the limitations of 3rd party add-ins then there are several techniques you can use which come with the standard JMeter install. **All you require is a bit of imagination, a basic understanding of Groovy and the JMeter Switch Controller.** The resulting JMX script can be downloaded here. ## Build a simple test Before we add any sort of complexity into a scenario let’s build something simple that we can add to. If you have not already done so I would recommend installing: - JMeterPlugins-Standard, - JMeterPlugins-Extra, - JMeterPlugins-ExtraLibs. Using either the recommended approach of using the Plugins Manager or downloading from the [JMeter Plugins Site](https://jmeter-plugins.org/ "JMeter Plugins Site") and copying to the lib folder of your JMeter installation directory. We are going to use **Dummy Samplers** to demonstrate the building of our complex scenario and this sampler is not part of the standard JMeter install which is why we recommend you install the plugins above. ![Dummy Samplers](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-1.jpg "Dummy Samplers") You can see from the screenshot that we have created six [Dummy Samplers](https://jmeter-plugins.org/wiki/DummySampler/ "Dummy Samplers") that are just artificial requests that generate an artificial response. The purpose of creating this is to demonstrate that **if we run this test we see a sequential execution of the samplers.** ![Dummy Samplers Execution](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-2.jpg "Dummy Samplers Execution") ## Adding Complexity If we wanted to use our samplers to create a more complicated scenario we could just copy and paste them any number of times into the JMeter UI. In our extremely simple example we may end up with something like this. ![Dummy Samplers Multiple Times](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-3.jpg "Dummy Samplers Multiple Times") Which would work but is **not particularly elegant** and would be time consuming to maintain if one of the samplers was to change. ## Switch Controller This is where we introduce the [Switch Controller](https://jmeter.apache.org/usermanual/component_reference.html#Switch_Controller "Switch Controller") which to be honest is **not going to magically help us in the creation of complex scenarios** in JMeter but we will come to that bit soon. The Switch Controller is to quote from the JMeter documentation: > **The Switch Controller acts like the Interleave Controller in that it runs one of the subordinate elements on each iteration, but rather than run them in sequence, the controller runs the element defined by the switch value.** Most of you who have used pretty much any programming language will be familiar with this concept but for those that are not let’s look at an example. Firstly, we will add a Switch Controller to our original example. ![Switch Controller](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-4.jpg "Switch Controller") As you can see we have added a Switch Controller and moved our Dummy Samplers underneath this controller. If we enter a switch value of 1 and execute our test again. ![Create Policy Sampler](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-5.jpg "Create Policy Sampler") We see that the **Create Policy** sampler has been run. That's because it is the sampler at position 1 under the **Switch Controller** as the controller uses a zero-based numbering system. The Switch Controller also takes a string to identify the sampler to call, if we replace the Integer with the String ‘UpdatePolicy’. ![Update Policy Sampler](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-6.jpg "Update Policy Sampler") And re-execute the test. ![Test Execution](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-7.jpg "Test Execution") We see that the sampler we identified by name has been executed. Now you still might be thinking this is all well and good **but how does it help me in creating complex scenarios**, we will move onto that now. ## Using a JSR223 Sampler This is where we can really **leverage the power of the Switch Controller** and we do this simply by adding a [JSR223 Sampler](https://jmeter.apache.org/usermanual/component_reference.html#JSR223_Sampler "JSR223 Sampler") to our test. You can see that we have added it above the Switch Controller. ![JSR223 Sampler](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-8.jpg "JSR223 Sampler") Let’s look at the JSR223 Sampler and look at what we are doing. We start by declaring a variable of type [Int](https://www.ibm.com/support/knowledgecenter/SSGU8G_14.1.0/com.ibm.sqlr.doc/ids_sqr_122.htm "Int") and then assigning the current iteration value to that variable, so every time we iterate the Thread Group this integer will increment. ```java // Declare a variable of type Int int iterationNo; // Assign the iteration number to a variable iterationNo = vars.getIteration(); ``` Next, we define our sequence of samplers as a [String Array](https://www.w3schools.com/java/java_arrays.asp "String Array"). ```java // Define our test sequence testSequence = ['Logon', 'CreatePolicy', 'UpdatePolicy', 'CreateClaim', 'UpdateClaim', 'CreateClaim', 'UpdatePolicy', 'Logoff', 'Logon', 'UpdateClaim', 'Logoff'] as String[] ``` Finally, we assign the Array element at the position defined by the current iteration to a variable called SWITCH_VALUE. We have **subtracted 1 from the iterationNo variable** because, as we discussed earlier, the Switch Controller is zero based. ```java // Assign to our variable SWITCH_VALUE vars.put("SWITCH_VALUE", testSequence[(iterationNo -1)]); ``` If we now replace the value in the Switch Controller with our variable. ![Switch Controller Variable](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-12.jpg "Switch Controller Variable") And set our Loop Count in the Thread Group to equal the number of values we have in our testSequence Array. ![Set Loop Count Value](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-13.jpg "Set Loop Count Value") We can now run re-run our test. ![Switch Controller Executed](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-14.jpg "Switch Controller Executed") We can see that the Switch Statement has executed each of our tests in the order they appear in the testSequence Array. As you can see there is also the JSR223 Sampler being output to the results, **if we want to tidy this up** we can by adding a new line of code to our JSR223 Sampler: ```java // Ignore the response, we do not want to report on this SampleResult.setIgnore(); ``` We now re-run our test. ![Test Execution](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-17.jpg "Test Execution") And we can see from our results that we are only reporting on the Samplers we have defined in our testSequence Array. ## Final Touches **There is one more thing we can do to this test as a final touch** and that is to set the Loop Count in the Thread Group to be populated depending upon the size of the testSequence array rather than defining it manually. This way if you want to add more test samplers to your complex scenario its just a case of adding these to the array and run the test. To do this we create a setup Thread group and add a JSR223 Sampler to it. ![setUp Thread Group](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-18.jpg "setUp Thread Group") Our JSR223 Sampler contains these lines of code. ![JSR223 Post Processor Code](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-19.jpg "JSR223 Post Processor Code") Let’s look at the JSR223 Sampler and look at what we are doing: ```java testSequence = ['Logon', 'CreatePolicy', 'UpdatePolicy', 'CreateClaim', 'UpdateClaim', 'CreateClaim', 'UpdatePolicy', 'Logoff', 'Logon', 'UpdateClaim', 'Logoff'] as String[] ``` We have moved the testSequence Array to here. ```java props.put("TEST_SEQUENCE", testSequence); ``` We have assigned our Array to a property called TEST_SEQUENCE. ```java props.put("ITERATION_COUNT", testSequence.size().toString()); ``` And finally assign the size of the testSequence [array](https://www.w3schools.com/java/java_arrays.asp "Array") to a [JMeter Property](https://jmeter.apache.org/usermanual/functions.html#__P "JMeter Property") called ITERATION_COUNT. If we now replace our static Loop Count value in the Thread Group to use our ITERATION_COUNT Property. ![Replace Static Loop Count](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-23.jpg "Replace Static Loop Count") And make a change to the JSR223 Sampler to use our testSequence Property value. ![Use Property Value](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-24.jpg "Use Property Value") The previous testSequence Array has been commented out to show the difference between the two. We can now run our test and get the same results again, only this time with no hardcoded Loop Count. ![Test Execution](https://blog.octoperf.com/img/blog/complex-scenarios-simply/ss-25.jpg "Test Execution") ## Conclusion There are many ways to build complex scenarios but by **minimising the number of samplers and using some simple JSR223 Sampler logic** to manage the flow of the samplers you can accomplish this is a straightforward way.