Below are some suggestions when debugging [[k6 (tool)|k6]] load testing scripts. Note: many of these options are quite resource-intensive and should be disabled during load test execution. ## Within the script ### Logging Use `console.log()` at strategic points in your script to print out values and other logging information at runtime. ### Using checks [[Checks in k6]] can be used to verify responses at each step. It's good practice to include a check for every action the user takes, so that it's easier to find out the exact point at which the script has failed. Otherwise, you might spend time debugging one request and response pair when the real scripting error occured several pages ago. ### HTTP debug flag Use the flag `--http-debug="full"` when running your k6 tests. `k6 run test.js --http-debug="full"` This flag will output the response bodies of your requests as well as the response and request headers. Not include `="full"` will only show the headers. ### Streamline script structure Modify the structure of your script so that it's easier to comment out certain transactions. Removing everything but the faulty transaction helps to cut out the noise when debugging. For example, here's a sample default function: ```js const domain = 'https://nicolevanderhoeven.com'; export default function () { Home(); ThinkTime(); Notes(); ThinkTime(); } ``` Instead of putting all the transactions in one function, I've created a function for each one, and then I call the transactions within the default function. That way, if I want to just troubleshoot `Home()`, for example, I can comment out just the three lines below it. For business flows that are made of several transactions each, you can separate them out further into another script, called by the one main "runner" script. [^miseur] This is called [[Modular scripting in k6]]. ## Custom summary output ## [[Using proxies in k6|Use a proxy]] You can use a [[Web Proxies|web proxy]] with k6 by running the command: ```bash HTTPS_PROXY="https://localhost:8888" k6 run test.js ``` You can also use `HTTP_PROXY` if more appropriate. Replace the port number with the port number of the web proxy you're using. [^tom] ## Use [goja debugger](https://github.com/mostafa/goja_debugger) [[Mostafa Moradian]] and [[Mihail Stoykov]] wrote a beta of a [[Goja]] debugger that can be used to step through, line by line. ## Resources _My video on How to debug k6 load testing scripts, with Tom Miseur:_ <iframe width="560" height="315" src="https://www.youtube.com/embed/Zln_TWOuoho" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> [^tom]: Miseur, T. (2021). _k6 load testing debugging using a web proxy_. Retrieved from https://k6.io/blog/k6-load-testing-debugging-using-a-web-proxy . [[K6 Load Testing Debugging Using a Web Proxy]] [^miseur]: Miseur, T. (2021). _k6 eCommerce demo scripts_. Retrieved from https://github.com/grafana/k6-example-woocommerce