k6<\/a> is a developer-centric, free, open-source load testing tool that\u2019s been receiving a lot of attention lately. In 2016, the k6 team set out to build a great open source load testing tool (formerly known as LoadImpact<\/a>) and has been pushing out updates and improvements ever since. In early 2020, the tool reached two million test runs per month<\/strong>, so it\u2019s fair to say that its user base is already well established and if this growth trend continues, there should be even more to come.<\/p>\n\n\n\n In the industry, there has been a need for a load testing tool that is built for teams that everyone is able to use (from developers and testers to DevOps\/SREs). The k6 team achieved this, democratizing load testing by building an application written in Go, (seeking to squeeze as much performance as possible out of the hardware) while the scripting is done using JavaScript. As you could imagine, in a world where JavaScript ranks as the number one most popular programming language by Stack Overflow for three years in a row, having a load testing tool whose scripting is based in it is a great way to lure developers into trying and ultimately, sticking with it.<\/p>\n\n\n\n First of all, as I previously mentioned, the fact that its scripting is based in JavaScript is a highlight of k6. Nowadays, full-stack JavaScript developers are more common, so they\u2019re able to integrate a load testing tool into their workflow without having to adjust much or learn new languages\/UIs. However, that doesn\u2019t mean it\u2019s hard to use if you don\u2019t know JS: I\u2019ve spent no more than 150 hours using JS, mostly working with WebdriverIO and Angular and I had no problems at all getting k6 to do whatever it was I wanted it to do. What I mean by this is that the barrier to entry is low<\/strong>, if there is any at all.<\/p>\n\n\n\n Next is the fact that k6 has really good documentation<\/strong> (https:\/\/k6.io\/docs\/<\/a>), however, there are certain things that you may find hidden where you\u2019d least expect and it’s lacking in some specific examples for how to do things. <\/p>\n\n\n\n Another remarkable thing is the number of integrations that k6 manages to handle.<\/strong> You can convert a HAR file to a k6 script, which means you can record a workflow in your browser or in a web debugging proxy tool such as Fiddler or Charles Proxy, save it, and then convert it to a ready-to-go k6 script. <\/p>\n\n\n\n I also find it impressive how you can convert JMeter scripts, Postman collections and even create a script from an API\u2019s Swagger<\/strong> (I haven\u2019t yet tried any of these options myself but they\u2019re well documented on its website). As expected, k6 also easily integrates with the most common CI\/CD tools such as Jenkins, GitLabCI, GitHub Actions, CircleCI, and more. Finally, its results reporting is quite good.<\/strong> You can design custom metrics, checks (aka assertions, for those coming from JMeter), create an output of the test result in JSON or integrate it with a number of different data visualization tools such as DataDog, Grafana, or Kafka.<\/p>\n\n\n\n If you\u2019re coming from other popular tools such as JMeter or Gatling, you might find the way of doing certain things more difficult or somewhat \u201chacky.\u201d I\u2019ll give you two examples of this that I came across when trying to create a script that simulated some simple user behavior interacting with a dummy e-commerce website<\/a>.<\/p>\n\n\n\n First, if you try to group your requests (this might not be the only way to do it, but it was the way I found out) but want to say, get a value from a response to one of the requests in group A and then use it in group B, you have to declare the variable in the supergroup as undefined, then set it in group A and then use it in group B. In JMeter, this is easier to achieve and doesn\u2019t require as much trial-and-error.<\/p>\n\n\n\n Finally, there is no easy way to perform general checks or set acceptance criteria for the whole test. What I mean by this is that when using different groups as I did, you can\u2019t define an error percentage or response time threshold for all of the requests inside each group from the \u201cmaster\u201d group. You can either go ahead and repeat the same checks in each of the subgroups or define custom rates which will act as general checks, but it would be nice to have that feature readily available rather than having to go through the trouble of defining custom checks. This could also be accomplished if Taurus<\/a> offered a k6 runner, which is not yet implemented. <\/p>\n\n\n\n For k6, I think the fairest comparison you could make against similar tools is with Gatling<\/a>. <\/p>\n\n\n\n If you aren\u2019t familiar with Gatling, <\/strong>check out this review<\/strong><\/a> or listen to this <\/strong>podcast episode<\/strong><\/a> featuring its CEO, Paul-Henri Pillet. <\/strong><\/p>\n\n\n\n For me, the barrier to entry is lower with k6 than Gatling. My reasons for this are the fact that JavaScript is more widespread than Scala and also because I found k6\u2019s docs to be more helpful than those of Gatling.<\/p>\n\n\n\n Parameterization is easier with k6. In Gatling, if you want to change, for example, the number of VUs between runs, you first need to declare a variable in your script, which will then take the value from the maven parameters passed when running the script. However, in k6, you can have a hardcoded value for VUs in your script, run it, then run it again passing a flag and overwrite that value, without needing to touch the script.<\/p>\n\n\n\n Maintenance is easy using both as they\u2019re designed with the \u201cload tests as code\u201d mindset and simulations should be stored in some sort of version control system. Gatling also supports a wide variety of protocols either natively or with help from its users\u2019 communities while k6 only supports HTTP1.1 \/ 2 and WebSockets. When it comes to reporting, I\u2019d say Gatling is the winner today since k6\u2019s built-in reporting is not quite as advanced. One of Gatling\u2019s best features is its automatic report generation, which creates a really nice webpage that allows you to clearly view and navigate the vast amounts of data logged by the tool. It\u2019s even clearer when executing, while k6 displays little to no information on the terminal when running a simulation until it ends, Gatling has some real-time reporting. In any case, these tools can be integrated with some other open source solution to improve the real-time reporting, such as ELK or Grafana. This capability is important, for example, to cut a test run short if you see failures are happening. However, if integrating k6 with other tools for better data visualization is an option, you can produce really great reports that way. As for distributed load testing, it becomes a bit muddier. Both tools offer a paid, cloud-based version that better support reporting and distributed executions. Gatling however, also offers a free shell script which allows you to distribute your simulation amongst as many machines as you\u2019d like. This script does require some previous configurations in all of the generators though. On the other hand, the k6 team states that its tool is more performant than its competitors\u2019, thus reducing the need for distributed load testing since you can supposedly generate serious load on a single generator, although we couldn\u2019t check this claim (the test sites we were using started rejecting requests when the load got heavy). It seems to me though that this argument falls flat when, for example, you want to distribute the load between different geographic areas in order to simulate more real-world scenarios. <\/p>\n\n\n\n If you\u2019ve made it this far through my k6 review, thanks for reading\u2014and I\u2019ve got to say, I like k6, far more than I thought I would<\/strong>. I believe it has a lot of potential and it\u2019s clear that the k6 team is highly involved, focused on improving it so that it\u2019ll continue growing its user base and features. I encourage anyone interested in new load testing tools to take a crack at k6 and let me know what you think about it in the comments! <\/p>\n\n\n\n 3 Key Performance Testing Metrics Every Tester Should Know<\/a><\/span>The Mission Behind k6<\/span><\/h2>\n\n\n\n
<\/span>The Good<\/span><\/h2>\n\n\n\n
![\"screenshot](\"https:\/\/abstracta.us\/wp-content\/uploads\/2021\/01\/unnamed-min.png\")
<\/figure>\n\n\n\n
<\/p>\n\n\n\n![\"k6](\"https:\/\/abstracta.us\/wp-content\/uploads\/2021\/01\/unnamed-1-min.png\")
<\/span>The Not So Good<\/span><\/h2>\n\n\n\n
<\/span>Comparing k6 to Gatling <\/span><\/h2>\n\n\n\n
<\/span>Ease of Use<\/span><\/h3>\n\n\n\n
<\/span>Parameterization<\/span><\/h3>\n\n\n\n
<\/span>Test Maintenance<\/span><\/h3>\n\n\n\n
<\/p>\n\n\n\n<\/span>Reporting<\/span><\/h3>\n\n\n\n
<\/p>\n\n\n\n<\/span>Load Distribution<\/span><\/h3>\n\n\n\n
<\/p>\n\n\n\n<\/span>The Final Verdict<\/span><\/h2>\n\n\n\n
<\/p>\n\n\n\n
\n\n\n\n<\/span>Recommended for You<\/span><\/h2>\n\n\n\n
14 Best Performance Testing Tools & APM Solutions<\/a><\/p>\n\n\n\n