When someone new joins the company, they're encouraged to do what is called a "Week of Testing" - taking k6 for a spin and presenting your findings to the rest of the team. This article will show you how you can make your test scripts more readable and maintainable. To do that, I'll test a demo application with a custom DSL. DSL is short for a Domain Specific Language, and in this case, it allowed me to write meaningful code specific to our business requirements.
I used demo app and checked that it continued to work as expected under load. During my experiment I noticed I was duplicating code in my scripts, for instance:
- getting from, or posting to a URL
- checking for a specific text in the body
- extracting a CSRF token
So I created a tiny DSL (Domain Specific Language) on top of k6's http module and figured more people might find it useful. The DSL allowed me to write the following test concisely:
Let's take a look at how these little functions work under the hood.
With the request function, you can:
- use a specific http method like GET or POST
- and check the response using a checker function
You can also execute handlers on specific events like on-connect, on-fail, or on-ok.
There are other helpers as well, like:
- bodyShouldContain, which is a checker funtion that looks for a specific text in the response body
- extractCSRFToken, which extracts the CSRF token from a form
- rsleep for sleeping a random amount of time
The first test checks whether the "my messages" screen is protected. The script calls the fail handler if the body doesn't contain "Unauthorized". Otherwise, the script calls the ok handler. The script also calls the connect handler once k6 connects to the website.
The second test checking whether a user can log in with valid credentials. Here, it needs to extract the CSRF token from the previous response object for the current session. Then, it checks whether the body contains the text: "Welcome, admin!" Finally, the script increments the fail/success metrics depending on the bodyShouldContain check.
The third test is for checking whether a user can log out. To do that, the script needs to use the CSRF token as well as the cookies for the current session. After logging out, it checks whether the body contains the text: "Unauthorized". Another test could be about whether we see the login screen after logging out.
The last test is for whether we cannot log in with invalid credentials.
The script uses the ramping VUs to simulate a relatively realistic load, and it has three stages. These are the testing goals and, at the same time, failure conditions. It also uses abortFail to abort the test if the failure rate exceeds 10%. check_failure_rate is a custom metric that I showed you before.
In case you're wondering, there were 82 successful VU iterations in total for my test app. All checks were successful. There were 574 requests in total because of the redirects. You can improve upon this tiny DSL and create your DSLs for your specific business requirements, and that way create maintainable tests.