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 .
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 .
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 .
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 .
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 . 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).
@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…)