Functional Testing 03: Let’s Be Lazy

Third in a series focusing on using JMeter for functional testing of an API.

Sometimes laziness is a good thing. Sure laziness can result in nothing getting done. But laziness can sometimes result in MORE getting done. So let’s strive to be lazy, but lazy in a way that empowers us to do more!

In this tutorial, we will take what we’ve learned about Samplers and Variables, and combine it with some new concepts that will make our work reusable across our test plan. We will learn how to create a library of samplers which are parameterized to allow us to call them many different ways in many different tests.

  • I like to use the Plugins Manager to install plugins to JMeter. You can install it from here.
  • Before beginning this tutorial you will need to install the Parameterized  Controller plugin for JMeter. Select Options > Plugins Manager, then click available Plugins, search for Parameterized Control, check the check box next to it, and click the “Apply Changes and Restart JMeter” button.
  • If you are not familiar with JSON, you should probably read up on it as the test API will use JSON extensively. A good introduction is here.
  • Open the test plan you have been working on in Functional Testing 02 or download this one here.

In the first two tutorials we made one stand-alone HTTP Request Sampler which called the info API and would pass if it got a good response. In this tutorial we will create a new Sampler but instead of creating it in such a way it could only run one test, we will create it in such a way as we can use it for many tests. Since we will be automating a SignIn API, we will want to be able to run a test on the same SignIn API with different usernames and passwords.

Functional Testing 03: Let’s Be Lazy

  1. First, since we are going to be automating the SignIn API let’s add the URL resource to our UDVs. Click the API Resources UDV table under the test plan.
  2. Add a new row and
    Set Name as “URL_Signin
    Set Value as “${API_ROOT}users/signin
  3. Right-click on the test plan and select Add > Test Fragment > Test Fragment and drag it to just underneath the View Results Tree. Name it Sampler Library.

    A Test Fragment is a way of partitioning off Samplers and other objects so that they will never be run on their own. In our Sampler Library we will create parameterized Samplers which can be run from our tests using Module Controllers.
  4. Right-click on the Sampler Library and select Add > Logic Controller > Simple Controller. Name it SignIn.

    A Simple Controller is just another way to group object. We will use this one to contain our Sampler for calling the SignIn API.
  5. Right-click the SignIn Simple Controller and select Add > Sampler > HTTP Request. I like to name my Sampler with what they are actually doing so let’s rename the Sampler to “POST Signin“.
  6. Configure the HTTP Sampler using the same method we used to configure the Get API Info Sampler in the last tutorial.

    Set Server Name or IP to “${SERVER}
    Set Port to “${PORT}
    Set Protocol to “${PROTO}
    Set Method to “POST
    Set Path to “${URL_Signin}
    We’ve now configured the HTTP Request Sampler to call the Signin API. However, we are missing some very important pieces of information; username and password.
  7. Click the Body Data in the Sampler.
    The API expects the username and password as JSON in the request body.
    So in the text field of the Body Data tab enter:

    Notice what we did with the dollar sign and curly braces; we configured the JSON to refer to variables instead of a hard-coded username and password. This is so that we can now use this Sampler with any username or password values we want. All we need to do is make sure we set those variables before using this Sampler in a test.
  8. There’s one last bit of crucial information we must include in our library for this Sampler. We need to configure the Headers sent with Body data to the server, so the server knows what type of data it is receiving.
  9. Right-Click the Signin Tests Thread Group and select Add > Config Element > HTTP Header manager

    In the Header Manager add a row.
    Set Name to “Content-Type”
    Set Value to “application/json

    This will make sure a header is sent along with the request letting the server know to expect the Body Data in JSON format.
  10. Now lets see how we would use this Sampler in our Library! You did install the Parameterized Controller plugin right?
  11. Right-click the test plan and select Add > Threads (Users) > Thread Group to add a new thread group to the test plan. This is where we will add our Signin tests. Rename the Thread Group to “Signin Tests“.
  12. Right-click the Thread Group and select Add > Logic Controller > Transaction Controller and rename it to “Signin Test 1“. In the Transaction Controller check Generate Parent Sample.
    A Transaction Controller is a good way of segmenting JMeter test results. This transaction controller will roll up everything underneath it and nicely organize our results in the Results Tree.
  13. Right-click Signin Test 1 and select Add > Logic Controller > Module Controller
  14. Using the browser with in the Module controller expand Sampler Library and select Signin.
    A Module Controller exists only to reference and run objects that live somewhere else. In this case we are using it to run the Signin library.
  15. We have one last thing we need to do. We haven’t yet provided values for the username or password for the Signin Sampler to send to the server. If we were to run now, the call would be made with an empty username and password. You may be thinking we want to User Defined Variables to set these variables, but that won’t work because we would only ever have one value for username and password for all of our signin tests (see last tutorials note about UDVS). To work around this we will use a Parameterized Controller.
  16. Right-click on the Signin Test 1 Simple Controller and select Add > Logic Controller > jp@gc  – Parameterized Controller

    The Parameterized Controller will allow us to set a variable right before we want to use it.
  17. In the Parameterized Controller add a row
    Set Name to “username
    Set Value to “PeterParker
  18. Add another new row
    Set Name to “password
    Set Value to “Spider-man
  19. Drag the Module Controller into the Parameterized Controller.
  20. And now we should be ready to try running our test! Click the View Results Tree and run the test. If everything worked successfully you should see the Get API Info call as green and a Signin Test 1 as green.
  21. Expand Signin Test 1 and click on POST Signin.
    On the Request tab you should see the correct username and password being sent to the server.

    On the Response Data tab you should see that the server replied with a “token”.
  22. Let’s quickly add another test. Right-click Signin Test 1 and copy it.
  23. Right-click the Signin Test Thread Group and paste.
  24. Click on the new copy and rename it to Signin Test 2
  25. Expand Signin Test 2 and click on the Parameterized Controller.
    Set username Value to “TonyStark
    Set password value to “IronMan
  26. Click the View Results Tree and run again. You should now see two Signin tests.

    That’s how quickly we can now create tests! Not only that, but we now have a reusable Signin Sampler we can use in other tests that require the user to be logged in.

Lazy is Good

I hope you can see how being lazy actually works out for us in this instance. By doing the work of creating the HTTP Sampler once, then parameterizing it, we can easily and quickly create new tests with a minimal amount of work and future maintenance!

But You Used Copy and Paste!

Yup, guilty as charged. If you are like me then anytime you find yourself copying and pasting things you immediately cringe at the future work you may be creating for yourself having to support duplicate code/configurations that vary only slightly, if at all, from each other. Copy and Paste is easy at first and may seem like it’s the right kind of lazy, but in fact, it could cost us more effort in the future.

In this case the only difference between the two tests is the username and password we feed into it. We should be able to account for this without copy and paste, and we can.

I’ll show you in a future But Wait! post what we can do about the copy and paste we too lazily did in this tutorial.

A Note About Request Data

In this tutorial we sent information to the API via JSON in the Request’s Body Data tab. This isn’t the only way to send data though. If you need to send query strings or form data you would use the Parameters tab. Or if sending a file you would use the Files Upload tab and select files from on disk.


Tutorial Test Plan

Leave a Reply

Your email address will not be published. Required fields are marked *