Why JavaScript is the best programming language for the QA domain

I’m the author of an online course to teach you JavaScript from scratch, no prior knowledge required. Together, we’ll build an interactive web app, complete with backend and frontend. Check out the course here.

I think that JavaScript is by far the best programming language you can choose if you work in the QA domain. Here’s why.

Popularity

To start, one of the simplest reasons: JavaScript is pretty darn popular. In fact, it reaches year after year the number 1 spot in terms of most used programming language by professional developers, as determined by the yearly Stack Overflow Survey, the last one being from 2023.

On top of that, JavaScript has a vast amount of use-cases. It is the language of the web and powers web sites and web servers. But you can even create desktop applications — don’t believe me? Visual Studio Code and Slack are written in JavaScript! Incredible, huh?

Popularity alone is a great reason why to use JavaScript in test automation: it’s an in-demand language that is used in thousands of companies. Definitely a great skill to have for your career and it means you can lean on a wide network of people for support.

Dynamically typed nature of JavaScript

In general, there are two types of programming languages: statically compiled languages like Java, Golang, C#, C, Scala etc., and dynamic programming languages like Python, Ruby, … and JavaScript. The “dynamic” refers here to the fact that in these languages, you don’t need to know the type of a variable beforehand. As you can imagine, this is a fantastic use-case for testing. Our test programs are supposed to react to all sorts of issues, including incorrect or missing data types. With a dynamically typed programming language, that fail-switch is already pretty much built-in. Let me give you an example.

Parsing JSON

A great example to demonstrate my point is by showing how to parse JSON data — this is something you will have to do a lot when testing, for example when making requests to a REST API and asserting that the response is correct.

Let’s imagine we have an API endpoint that responds with some basic information about animals, such as the below structure.

    {
        "data": {
            "animals": {
                "cat": {
                    "legs": 4,
                    "voice": "Meow",
                    "fur": true
                }
            }
        }
    }

Now, let’s assume we want to write a test to check how many legs a cat has in this response. First, let’s see how we would achieve that in Golang, which is a statically typed programming language.

    package main
 
    import (
            "encoding/json"
            "fmt"
    )
 
    type Animal struct {
            Legs  int    `json:"legs"`
            Voice string `json:"voice"`
            Fur   bool   `json:"fur"`
    }
 
    type Data struct {
            Animals map[string]Animal `json:"animals"`
    }
 
    type JSONData struct {
            Data Data `json:"data"`
    }
 
    func main() {
            // Let's assume I had some code to get the API response
            apiResponse := getResponseFromAnimalsEndpoint()
 
            var jsonData JSONData
            err := json.Unmarshal([]byte(apiResponse), &jsonData)
            if err != nil {
                    fmt.Println("Error:", err)
                    return
            }
 
            cat, exists := jsonData.Data.Animals["cat"]
            if !exists {
                    fmt.Println("Cat not found in JSON data")
                    return
            }
 
            // I can finally access the amount of legs on the cat!
            if cat.Legs != 4 {
                    // throw an error
            }
    }

And here’s how I could do something similar in JavaScript, a dynamically typed programming language — it’s a lot simpler.

    // Let's assume I had a function to get the response from the
    // animals endpoint and that would return a JSON string
    const apiResponse = getResponseFromAnimalsEndpoint()
 
    const parsed = JSON.parse(apiResponse)
 
    if (apiResponse?.data?.animals?.cat?.legs != 4) {
        throw new Error("Wait a minute, that cat doesn't have 4 legs!")
    }

There’s a reason after all why JSON stands for JavaScript Object Notation — dealing with JSON is incredibly simple in dynamic programming languages, but especially so in JavaScript. Hooray for testing!

Third-Party libraries

The joke about the disk size taken up by third-party dependencies in a JavaScript project is oft-repeated, but it serves my point: the JavaScript eco-system is full of incredibly useful libraries that make life much easier. There’s simply no better way to program than to use existing functions and methods without having to write everything from scratch.

In the testing space, I have a lot of favourites. The test runners jest and mocha are both very popular, but I especially like jest for its stability. The library AJV is simply fantastic to perform JSON schema validation, a fancy way of saying “test a received JSON against some expected requirements”. Axios makes it super easy to make network requests.

A special mention has to be made for browser automation frameworks, a topic about which I recently wrote another blog article here on qajobs.co. My unbeaten favourite there is Playwright, but other fantastic JavaScript based frameworks are Cypress and WebdriverIO. But this is only the tip of the iceberg; there are more, like Puppeteer and Nightwatch.

(By the way: if you are interested in browser automation, I have a highly rated online course that teaches Playwright from scratch. You can check it out here.)

Why are so many browser automation frameworks written in JavaScript?

All of the previously mentioned automation frameworks are written in JavaScript. As for why this is, there are two main reasons: for one, JavaScript is the programming language of the web. Thus, to developers that create browser automation frameworks, it makes a lot of sense to write their frameworks in JavaScript if the product they are testing (web sites) also use JavaScript.

On top of that, popularity plays again a big role: the more developers there are who know how to program in JavaScript, the more likely it is that a new tool would be created using this language. It’s a snow-ball effect!

Community

In my experience, the JavaScript community is ambitious but never snobbish. Unlike in other programming languages, it is rare to find a snooty code professor who doesn’t want to help people out but is prone to dispense critical wisdom. Instead, JavaScript programmers like to get things done and are eager to help out those who struggle.

This means that newcomers will get help, even with more mundane problems. Once again, this is great for test engineers who are often getting their feet wet with programming.

Simplicity

There I go, I said it: JavaScript is a comparably simple programming language. The fact that it is dynamically typed helps tremendously; unlike with statically typed languages, you don’t have to worry about memory management and other such problems. You don’t need to know what happens “behind the scenes” to create something useful.

But unlike many other programming languages such as Python and Ruby, JavaScript is built with concurrent programming in mind. This means that JavaScript programs can easily be designed to be fast and efficient, but one drawback is that there is an inherent need to use concepts like Promise or async/await, which do create some difficulties for newcomers. But in my experience, students get the hang of these eventually; and given the right teaching, they can learn even quicker. For example, in my JavaScript course, we are learning about Promises and async/await already 30 videos in. This proves that as long as you tackle it clearly, it can actually be simple! You can grab the course here.

Conclusion

You get the picture: JavaScript is awesome. Its high popularity comes from its dynamically typed nature, its great community, vast ecosystem of third-party libraries and of course the fact that it is so easy to pick up. JavaScript and the QA domain are truly a match made in heaven.