Possible to test a form containing a radio button selection?


Using K6, is it possible to select and submit a form that uses radio buttons?

We need to check the performance of this page & form when 400 users submit an answer at about the same time: https://forms.itcihub.com/test-quiz/?pid=rc123&eid=OTQzMjMw

I’ve been reading through the documentation and testing different things but I’m not confident I’m actually testing the form correctly.

Hi @jfarr,
AFAIK there is no difference between radio buttons and … any other input(at least as far as k6 is concerned). At the end what you send to the server is key=value pairs. The only thing radio buttons “do” is that the browser won’t let the user choose two options at the same time and you can predefine what values they can choose from. Of course again anyone can open the “developer tools” and change the values :wink: .

What I am getting at is that … if you currently test non radio buttons or any other kind of output someway you can test radio buttons the same way :smiley: .

Technically k6 does have the functionality to parse html in a response find a form in it and send it back, which in your example can be used as in:

import http from "k6/http";

export default function() {
    var res = http.get("https://forms.itcihub.com/test-quiz/?pid=rc123&eid=OTQzMjMw");
    // some checks of the response
    var res2 = res.submitForm({
        "formSelector": "#form_testquiz",
        "fields": {"item[101]":12}, // only this field will be overwritten

While this is probably okay for fast scripting you have a lot less control over what happens :smiley: .
You can use --http-debug=full to see what k6 actually sends although it is very noisy as the responses from the server are full html pages :wink: .

But as you can see in the above example I opted to send a value of 12 which is not available in the options on the page :smiley:. To get what the options are available you will need to use k6/html module and let’s just say it will be way too much work.

Again you are probably much better by hard coding what your requests body is, possibly using the har converter or the newer har-to-k6 with recording what your post are (I highly recommend against leaving your js/css request in as you are just testing your cdn … mostly inflating your bill).

1 Like

Hi @mstoykov,

This is super helpful and exactly what I needed to help get me pointed in the right direction.

I really appreciate you taking the time to explain.

… now how can I buy you a drink?! :beers:



Glad I could help!

About the drink … when Load Impact makes a k6conf we can meet there :wink: :beers:

1 Like

How does one go about removing the js/css requests?

@jfarr you can simply delete(recommended) or comment out those requests. k6 only makes requests that are in the script.

If you look at the example below, I’ve commented out two static assets for visualization purposes. This batch request would only request the test url.

        //    ["GET", "http://test.loadimpact.com/style.css", {}, { tags: { staticAsset: "yes" } }],
        //    ["GET", "http://test.loadimpact.com/images/logo.png", {}, { tags: { staticAsset: "yes" } }],
            ["GET", "http://test.loadimpact.com/"}]

@mark - That was a lot easier than I was making it. Thank you so much!


If I may be so bold to ask another question…

(I’m obviously super newb at this)

There’s something I’m not able to understand yet…

If the form is not actually getting submitted to the server, how do we know the server and/or database can actually handle an influx of submissions?

@jfarr All a form does is allow users to input data that gets sent in a POST(okay maybe some other methods too but it’s almost always POST). When you hit “submit” on your form, a POST is fired off with all the details. k6 makes that POST request and will send any POST body data along with it. In your case, whatever the form fields are.

Side Notes/caveats
If your form has any CSRF token or session ID to protect it, that can be a tricky thing to sometimes handle. If you are using the submitform API that @mstoykov mentioned above and any such token is just a hidden form field, you probably don’t have to worry about it (that API only overwrites what you enter thus every time the VU gets the form from the page, it gets the updated value for hidden fields).

Also keep in mind: if your server doesn’t like the same data coming in over and over, that can cause problems. e.g. Let’s say a form field was “User” and each user was only allowed to submit data once - that can cause a problem. You can also sometimes run into caching issues. Either way, parameterization is the best way to solve this.

TL;DR we are making requests. If you aren’t seeing requests, something else is at play here (which is why I shared the other notes…)