Second in a series focusing on using JMeter for functional testing of an API.
A little preparation will save us tons of time later when everything changes. And everything is always certain to change.
After the fun excitement of the first tutorial in which we made our very first API call with JMeter, we are going step back and do some very boring preparation for the future. One thing we can be certain of is that changes happen in software projects. A small amount of effort put in early in a project can greatly help reduce the headache of updates and maintenance later down the timeline. So in this tutorial we start venturing down the path to setting up our test plan to be able to weather changes in API location, paths, and http ports, and more.
Functional Testing 02: Preparation is the Key to Success
- Open the test plan you started working on in Functional Testing 01 or download this one here.
- Click on the “Get API Info” HTTP Sampler.
Notice all the hard coded information we created in this Sampler. The Server, Port, Path, and Protocol are all hard coded. If we wanted to make more tests on the Info API then we would need to fill this hard coded data in to every new HTTP Sampler we created.
If we ever needed to move the location of the API (say we moved it off of http://www.scottmollon.com) or if we create multiple deployments of the API (say we create a QA deployment and Stage deployment) we would need to edit and change every HTTP Sampler in our test plan to match wherever the API was we wanted to test.
If we make a few fairly simpler changes to how we set up JMeter, and follow a pattern utilizing JMeter’s Parameters and User Defined Variables, we can make adjusting to changes much easier. - Click the test plan.
Here we can see the high level User Defined Variables for the test plan. We can define values on this page that we can use through out all of our tests. This is where we will choose to keep the high level values we use in our HTTP Samplers. - Click the Add button at the bottom of the empty User Defined Variable (UDV) list. In the new row:
For Name enter “PROTO”
For Value enter “http“ - Click the Add button again. In the new row:
For Name enter “SERVER”
For Value enter “www.scottmollon.com“ - Click the Add button again. In the new row:
For Name enter “PORT”
For Value enter “41431“ - Click the Add button again. In the new row:
For Name enter “API_ROOT”
For Value enter “/learnjmeter/api/“ - We now have four variables we can use throughout our tests to help target where the API call will be made.
- There is one other piece of data we can extract from being hard coded in to the HTTP Sampler and that’s the Path. We couldn’t add it test plan’s User Defined Variables, because a UDV can’t reference another UDV within the same table. Our Path will depend on the API_ROOT so we need to put it somewhere else. Additionally, I just like to set the API resources apart for clarity as well.
- Right-click the test plan and select Add > Config Element > User Defined Variables. Then drag the new UDV table up just below the test plan.
- In the Name field enter “API Resources“.
- Click Add below the list of UDVs. In the new row:
For Name enter “URL_Info”
For Value we are going to build the URL of the info resource, and we will do so by using the API_ROOT variable we defined on the test plan.
For Value enter “${API_ROOT}info”
See that part with the dollar sign and squiggly brackets? That’s how we reference a variable in JMeter (well one of the ways). This will expand out to “/learnjmeter/api/info” when used in our tests.
- Now click on the “Get API Info” HTTP Request Sampler again. Let’s start replacing our hard coded data with the variables we created.
For Server change the value to “${SERVER}”
For Port change the value to “${PORT}”
For Protocol change the value to “${PROTO}”
For Path set the value to “${URL_Info}”
Your HTTP Request Sampler should look like this.
We have now configured our Sampler to user a set of global variables in order to make the same API call. - Now let’s make sure everything still works! Click on the View Results Tree and run the test (Run > Start or click the green arrow in the toolbar). You should see a green result.
Let’s Reflect
In this tutorial we protected ourselves against API or deployment changes which would cause a lot of work for us to adapt to. We can now easily adjust to run our tests anywhere the API is located, with either http or https, and can react to API resource url changes.
This may not seem to be a big deal now with only one Sampler in our test plan, but once you have hundreds of Samplers, you’ll appreciate being able to go to one place to make a change that will update all your Samplers and all your tests.
Some Notes About User Defined Variables
User Defined Variables (UDVs) have some quirks about them. The most important one to know is that UDVs are all processed at the time the test starts. This means that if you place a UDV table with variable foo=10 at step 1 of a test and then later put another UDV table with the same variable foo=20 at step 5 of your test, the entire test will run with foo=20. All UDV tables are processed before the test begins and the last value of all variables will be used.
This can cause a lot of confusion especially if you are trying to use UDVs to control calling the same API with different inputs. Don’t try it. What you are looking for is something called a parameterized controller and I’ll introduce you to it in the next tutorial.
Downloads