Here is the correct way to test links in your web applications


[ad_1]

For a web application to run as expected, all clickable links must redirect users to specific and correct URLs. Unfortunately, there can sometimes be thousands of clickable and navigable links in a web application, making it tedious (and potentially unreliable) to check them all manually. And as we’ll see below, some link testing methods are unreliable.

Fortunately, robust tests for valid links can help. Those automate the processthus freeing up developer time and generally making the process of testing web application links more enjoyable.

E2E tests for valid links

Automated user interface testing encompasses many techniques designed to verify web applications without the need for significant human intervention. However, these can sometimes require substantial resources.

The key is to create an optimal test program using automated atomic testing. Over the past two years, I have dedicated my heart and soul to developing such a test for web applications. It makes it easier for developers to do the job.

To understand the value of these tests, see the following sample web application:

You can see at the bottom of this streamlined web application that it contains a link to “Learn Test Automation with Nikolay and Mia”. When users see the blue underlined text, they’re assuming it’s a clickable link that will redirect them to the page providing the information they want. But, as any seasoned developer knows all too well, the link may not work.

Of course, with a simple web app like this, you can test the link manually. But if there are thousands of links (or many apps), this may not be feasible. Also, just clicking on the link in the browser is not enough test. So, in these scenarios, it makes more sense to use an automated method.

When users click on the web app link, they should be able to do two things:

  1. Click on the link itself.
  2. Go to the correct web page by following the link.

Therefore, the E2E tests for valid links verify that the link is clickable and redirect users to the correct URL when they click.

How to create an automated atomic test for clicking on links

When it comes to creating automated atomic tests for clicking links, there is a right way and a wrong way to go about it. Let’s start with the wrong way.

You might assume that a test that clicks on links is the way to go. Unfortunately, everything in HTML is clickable. So if you test the clickability of these tags, it means you are testing HTML and not custom code. Thus, if the clickable feature of the feature does not work in this app, it will also be discontinued for all other apps around the world. This is native browser behavior, not behavior of our software.

In other words, you should not use this test to find broken links.

A better approach is to test whether the attribute is as expected. Why? Because the contains the two pieces of information that you want to test: the URL, which is the actual link, and the clickable text that appears on the web application page (usually called “anchor text”).

You can assess the value of to determine that it is doing what you think it should be doing using the following code:

The test will then tell you if the link is valid automatically by evaluating the code at the right level.

How to test valid links with unit tests

But you haven’t finished yet. There are even better ways to test the validity of your links on your web application. E2E tests are great – and they work – but they’re slow, require a lot of coding, and aren’t always robust. Unit tests are an upgrade; they work even better and fix many E2E testing issues. For example, they tend to be thousands of times faster, they don’t require as much code, and they work best on large samples.

Here’s an example of a unit test in action:

As you can see, the test only takes a fraction of a second (0.445 seconds). The output shows which links succeed and which fail, as a proportion of the total. The result is faster testing, the ability to check for more links, and the identification of broken links without the need for additional code.

Below you can see a simple ReactJS portfolio website for me which is hosted on a popular hosting solution:

At the bottom of the screenshot, there are links to four social media sites: GitHub, LinkedIn, Twitter, and YouTube.

This is a perfect opportunity to use unit link testing. It can verify that social links are clickable and redirect users to the relevant pages.

But how do you do this? If you inspect the code in more detail, you’ll find that it’s extracted from a JSON file that looks like this:

Therefore, your task is simply to determine the validity of the links. Since you already know that clicking on it is an unnecessary test, you will use the unit test.

You can write the unit test in Jest. Enter the following code:

When you use the above code for ReactJS Wallet website for Nikolay Advolodkin, you find that it fails the test:

In this case, failure is what you want as it shows that the links on the website are correct. The expected substring differed from the received substring.

In many ways, unit testing in this way is superior to just clicking on links in the browser. But the use of unit tests for links is still not optimal.

There are flaws. Can you see what they are? (Don’t worry, I’ll explain in the next section.)

How to optimally test valid links

The main disadvantage of the method described above is that you continually have to write more tests every time you add more links. In other words, testing all your URL links still takes a tremendous amount of time, even if you use the unit testing approach described above.

So what is the solution ? This is called the “snapshot test”. This approach allows you to flexibly check all your links without having to continually add new lines of code. In other words, it’s much simpler.

How it works? The clue is in the name. The test takes a snapshot of the current state of your UI components, then compares them to a benchmark snapshot file, instantly telling you if there are any differences. If there are any inconsistencies, it tells you. This means either:

  1. You need to update your snapshot file to match the new UI component; Where
  2. There is an incompatibility or an unexpected change in the UI component.

What does this test look like? Check out the following:

Here you can see that I wrote a test that allows the program to identify the differences between UI elements and the original stored snapshot, something I call the “expected object” .

You can retrieve the expected object from the resumeData.main.social part of the JSON file. This is how it appears:

To validate that the expected object matches the snapshot, you must use the following approach:

In this example, you want to know that the UI component contains the correct social profile links. If so, then there is no problem: the application passes the test and you are satisfied. If not, the test returns a failure message that looks like this:

Note that this method does not require any additional work. All you need to do is continue to compare the app as it currently is with your favorite snapshot. If you want to update the comparison, just save a new snapshot file.

Using snapshots is usually the most efficient way to test links stored in a JSON or other type of object. You can even perform a snapshot test on an entire web component with many links. Just make sure you focus on the exact area of ​​that component with the links. Otherwise, false positives are likely. Why not give it a go?

Find out more about mastering automated tests, register for the Advolodkin Complete Selenium Java Bootcamp. Enter your email and you will receive a coupon of 45% off the regular price of Black Friday (November 26, 2021).

Keep learning

[ad_2]

Comments are closed.