NEW! Root Cause - Open Source Project for Puppeteer and Playwright MORE

Frontend testing, 123: A search for the best tool

If anyone’s ever told you that testing your frontend is an easy job, don’t believe them. You want your tests…

Rookout blog
By Gilad Weiss,

If anyone’s ever told you that testing your frontend is an easy job, don’t believe them. You want your tests to seem as if it were a real human user doing them, while at the same time being easy to program and accommodate the fast times that agile development requires. See? I told you not to believe them.

So what do you do when you need to test (like, all the time)? Well, to begin with, the fast pace that is needed for testing requires not only fast coding but also a certain level of understandability of your code. For example, when you need to find out what went wrong and why your CI tests failed after build, because you need to deploy this feature *quickly*.

The better you understand the code and the underlying flow, the better you’ll be able to find the problems your tests might raise.

When speaking in terms of frontend tests, they’re especially important because they portray your company’s e2e tests. Therefore, they need to cover as many edge cases and touch components in your system as possible. So, when you have to test your frontend, what tool do you turn to in your moment of need? I tried Testim.io. Here’s what I learned along the way.

Test, Test Away

The first step on my journey was to go to Testim.io, a platform that helps developers test their Frontend. This is done by using their Testim Development Kit (TDK) and CLI, or by recording your own tests which can be exported to code. 

Before trying my comfort zone, testing using code, I tried using their editor. I found it to be quite fun and intuitive- all you have to do is press the button and move the cursor as *you* expect the user to behave. This was really useful in helping to enter the mind of the end-user. 

The testim editor comes fully featured. There are the right set of tools, steps that can be moved through easily, validations can be set on each step, the ability to set your visual components by simply clicking (and not by specifying a selector), as well as other visual scripting that is used to replace traditional coding of tests.

In my experience, working with just the editor itself is a great replacement for writing your tests using code. I’m usually not a big fan of visual scripting, but in this case, I found that Testim.io cracked the case of how to make writing tests a bit more pleasant for developers. But that’s not where it stops. The visual scripting also gives a solution to a specifically annoying segment and a big problem in frontend testing: selectors, maintaining selectors, and picking the right selector for a test.

Selectors are how the testing mechanism identifies your components so you can click on them, check their internal values, and wait for them to appear or disappear. When testing my code, I can do this by specifying a class, ID, or any attribute that can point to that single component you want to test. As time progresses, your code will do so as well, and you might need to get nested identifications to get your specific components and change your test each time your code changes. Here, all the headache is eliminated as you can just click, visually, on that component, and every run will keep using it, even if you changed its attributes.

One last cool feature that the editor offers is incognito mode, which allowed me to have a “fresh start” on each test without having to worry about cookies and other browser-related data. However, if you want to see your test dealing with ad-blockers, I’d recommend skipping this particular feature. 

Another Way of Testing

Apart from the editor, the other way that I was able to test what I needed to was by way of pure javascript (or typescript) code, using TDK and writing test commands inside a Node.JS project. The setup and running was quite easy, only necessitating an ‘npm install’ in the testim library and then using test() function to describe a test and write your commands as they imitate a human user. For example: go() changes your URL and other commands like click() and waitForElement() give you the freedom to test individual components and processes in your site.

Although adding your own JS function as a custom validation is a feature that is available on the site’s editor, writing the tests in the comfort area of your own IDE lets you create more complex tests for example using 3rd party libraries that you may need for your testing.

Similar to other libraries of frontend testing, grabbing your right selector needs a bit of practice when you want to be more precise. For example, nested selecting. For that, the TDK has a feature called Smart Locators that let you fetch the right selector.

Making A Choice

You might now be asking yourself, can I enjoy both worlds? Can I record my testing using the visual scripting method and build ON that more complex behavior? The answer here is a resounding yes. Testim.io lets you generate the recorded test into JS code for you to use and run anywhere.

While this might sound like a good idea, be careful since changing generated code can introduce errors. The generated code is expected to work as-is and you probably don’t know what you can mess up by changing the code. Also, in this case of frontend testing, in the event you change your visual components in a significant way, you’d want to record your test again. This causes integrating your changed generated code with the new one to be hard to follow through. The point is to use the generated code with precaution.

While this might sound like a good idea, be cautious, since changing generated code is error-prone. The generated code is expected to work as-is and you probably don’t know what you can mess up by changing the code. Also, in this case of frontend testing, in the event you change your visual components in a significant way, you’d want to record your test again. This causes integrating your changed generated code with the new tobe one less maintainable code.

Here is my recommendation: try to stick to one kind of testing. Whether it be visual scripting or code, it will make your day to day work easier when you don’t have to know two different kinds of testing. And sometimes, just sometimes, the easier way *is* the right way.

Real-life implementation

So after you’ve written your tests, now’s the time to sharpen your devops skills and implement them in your CI. I won’t get into that, but you can find countless articles online on the topic. However, keep in mind that when using Testim.io, they won’t give you a hard time using their service in your CI.

Of course, they also don’t forget to integrate with the main stars, the CI providers, which will run your frontend tests. If you’re humble and like to keep it simple, you can run in your containers the npm start and use the results right there in your CI pipeline. Testim.io also lets you use their CLI, which will allow you to connect to your project on their site and get reports with detailed test results. 

On Rookout we take our tests very seriously. We not only use tests on each branch build and before deployment but also run tests as crons at fixed intervals. It was really cool for me to see that Testim.io has a feature that lets us run our tests chronically.

The bottom line is: just like brushing your teeth, testing your frontend shouldn’t be skipped, and I’ve found that Testim.io is a great tool to do just this.

Gilad Weiss is a full-stack developer at Rookout.com

Testim's latest articles, right in your inbox.

From our latest feature releases, to the way it impacts the businesses of our clients, follow the evolution of our product

Blog Subscribe