JavaScript allows complete freedom when it comes to developing web applications.Period! Using JavaScript provides enhanced functionality to your site and helps you adopt the latest web design trends while ensuring a great user experience.
However, this freedom often comes at a cost — you need to amplify the efforts of testing your application for potential bugs. Leveraging automation testing to test JavaScript code can help you scale faster, easier while offering reliability.
Automation testing comes with its own set of challenges — test flakiness, scalability, reliability,etc. These challenges can outrun the overall purpose of testing. Implementation of readable and scalable test code often results in higher test coverage, minimal breakage, and enhanced team collaboration.
As per StackoverFlow Developer Survey 2020, JavaScript is one of the widely used programming languages; a coveted rank that it has held for the 8th year in a row! To make the most out of features offered by JavaScript, it is important to incorporate the best practices in the implementation. In this blog, we cover the top 13 JavaScript testing best practices that will help you come up with scalable and reliable automated test scenarios.
Choose Behavioral Testing
When you run unit tests for your JavaScript code, it’s essential to think from a tester’s perspective and not from the developers’ point of view. Following this approach, you will save time by avoiding things that are not required to be tested on a priority basis. For example, you should avoid testing internal variables of your code.
it('should login with valid credentials, () => {
userManager.login('UserId', 'Password');
expect(userManager._usersList[0].name).toBe('UserId');
expect(userManager._usersList[0].password).toBe('Password');
});
Here, the user tries to login into a web application using a specific credential chosen from a list of credentials. Since, the test script is implementational, it is better to rewrite the same in the following manner:
it('should login with valid credentials', () => {
userManager.login('UserId', 'Password');
expect(userManager.login('John', 'Password')).toBe(true);
});
Using this approach, we avoided the use of internal variables and still managed to return the necessary result. As a result, whenever there is a change in the implementation, we don’t have to change the test scenarios.
This practice not only improves the scalability of the tests but also helps your team members in deeper understanding of the test cases. It is considered one of the best practices in JavaScript testing that will help you build more reliable (or less flaky) test cases.
Decide When to Perform Unit Testing
There are a few misconceptions associated with unit testing. Before testing your JavaScript code, you should know that not every test is a unit test!
View Website
View Website
View Website
Consider the following scenario — A script that reads a file from the disk or adds tables into a database. For such kind of implementation, you need not perform unit testing.
Unit tests don’t deal with external systems, as unit tests are performed at the unit level. If a test fails when running on a system without proper configuration, the test does not count as a unit test.
For complex functionalities, it is recommended to write end-to-end tests, functional tests, and integration tests. Those tests do the job of testing features when different modules are integrated with each other. You can use the Selenium framework to write functional tests and more.
Follow Shift-Left Testing
A Test-Driven Development(TDD) is focused on improving the code quality and enabling a shift-left approach across the project.
Shift-left approach states that you should write your test cases describing the behavior of the code as soon as you get the requirement. This practice helps in finding defects earlier in the software delivery cycle.
Though writing the test cases before coding does not guarantee a complete error-free code, it does result in maximum test coverage. End result is code that adheres to the business requirements.
Let’s discuss how to implement TDD with JavaScript. Suppose we are writing a test that comprises of the following steps for form validation:
-
Read values from fields
-
Invoke numerical (or alphabetical) rules against the value
-
If invalid, return an error
In our form, we are validating only the name and contact fielda. We have to start with the following script:
it('should validate a form with all possible data types', function () {
const name = form.querySelector('input[name="first-name"]');
const contact = form.querySelector('input[name="contact"]');
name.value = 'John';
age.value = ‘9051513622’;
const result = validateForm(form);
expect(result.isValid).to.be.true;
expect(result.errors.length).to.equal(0);
});
Here is the HTML form used for validation:
form class="test-form">
<input name="first-name" type="text" data-validation="alphabetical" />
<input name="contact" type="text" data-validation="numeric" />
</form>
Since we have not written any code for form validation, the test will fail. To make sure you successfully pass the test, write and execute the required codes for validation.
You can take this certification as proof of expertise in the field of test automation with JavaScript to empower yourself and boost your career. Now execute free JavaScript automation testing online!!!
Here’s a short glimpse of the Selenium JavaScript 101 certification from LambdaTest:
Know When to Stop Testing
Test-Driven Development aims to increase test coverage. As a project manager, the higher the coverage, the better the result. However, the ideal way is to know when to draw the line! It is also important to understand the difference between code coverage vs. test coverage.
If you ask someone about the ideal test coverage, you will hear numbers like 100% or an absolute minimum of 80%. However, if a target is given to your team, they will try to achieve arbitrary coverage. As a result, there is a chance that some critical functionality might remain untested.
So, what is the ideal coverage? Sadly, it can’t be answered! If you are performing Selenium test automation, it’s challenging to get high coverage since it takes a huge amount of time to write good scripts. This is more critical in the cases where you keep cross-platform and cross browser testing as a priority.
<script></script>What are you working on today?
— Hashnode (@hashnode) June 14, 2021
Happy Monday 🤗#hashnode #devcommunity
As test maintenance can be very tedious, it is important to have awareness about how to maintain tests in Selenium. Every change in the code should pass the testing phase, which means that you should do better when it comes to branch coverage.
Make Test Automation Framework Portable
I have seen test automation engineers spending a lot of time in configurations — a practice that does not yield results in large-scale projects. A script that runs perfectly on the system where the framework was created often causes issues while running on other systems.
What if you are about to run the tests on a CI server? If your UI test automation framework is not portable, testing can just get trickier! As a result, we cannot miss out on adding it to our list of JavaScript Testing best practices.
Firstly, don’t store the files for test automation on your local system. Instead, attach the required files to the framework. If the files are big, you can use cloud storage like Amazon S3. Also, if you are using Selenium, you can avoid the configuration issue by using a cloud-based testing platform. You should leverage Page Object Model (POM) in Selenium to separate web locators from the code logic so that changes in the UI involve modifications in the web locator repository (and not the test code).
LambdaTest provides an online selenium grid that allows you to perform Selenium test automation on a secure, scalable, and reliable cloud infrastructure. Supported with 2000+ browsers, browser versions, and platforms, LambdaTest helps you with hassle free testing experience on the cloud.
Moreover, performing Selenium test automation on LambdaTest cloud grid helps you achieve better browser coverage, accelerated test execution, and faster product release. Furthermore, parallel testing in Selenium is one of the major advantages of running tests on a cloud-based Grid like LambdaTest.
Hey are you looking for a StaleElementReferenceException, This happens when the referenced web element isn’t attached to the DOM.
Choose Logical Test Names
This is one of the most under-rated best practices in JavaScript testing. However, following a proper naming nomenclature for function, variables and tests is considered to be a good programming practice.
The names of your tests should be clear enough to provide an idea of their purpose. Here are the major reasons for choosing logical test names:
-
Provides test’s objective in a much better manner
-
Provides easy identification if there is any breakage in the functionality
-
Enhances the reusability of test cases and reduces the time spent in knowledge transfer.
Here is an example of a non-recommended test name:
[@Test](http://twitter.com/Test)
public void employeeSearchTest() {.....}
It is bad because it does not tell you about the test scenario.
Here is an example of good test name:
[@Test](http://twitter.com/Test)
public void userShouldBeAbleToSearchEmployeeNameFromDatabase() {.....}
Prefer BDD Approach
Like TDD, BDD (Behavior Driven Development) is a methodology to increase code coverage and test coverage. BDD focuses on continuous communication and a shared understanding of the software product amongst the developers & engineers. This understanding is achieved by creating scenarios of the desired behavior of the product.
UI automation is one of the main areas where BDD can be extremely helpful. Here is a sample demonstration of the BDD framework:
HomePage homePage = new HomePage();
homePage.open();
homePage.waitUntilPageLoaded();
Assert.assertEquals(homePage.getTitle(), "FlightBookingDemo");
Assert.assertEquals(homePage.getTitle(), "Welcome to the Flight Booking Demo Site!");
FlightsPage flightsPage = homePage.findFlights("Bangalore","Mumbai");
List<String> foundFlights = flightsPage.getFlights();
Assert.assertTrue(foundFlights.size() > 0);
As a test automation engineer, you might be familiar with such scripts. However, for business managers, such scripts are often out of context. Now, let’s imagine you find a script written like the following in a simple English-like language (i.e. Gherkin):
Given that a user opens the home page
The user should view a homepage with title "FlighBookingDemo" and heading "Welcome to the Flight Booking Demo Site!"/
When the user searches for flights from Bangalore to Mumbai
Then the user should find some flights
This is how BDD is written in Cucumber. For reference, you can also check our BDD with Cucumber tutorial. BDD helps in reducing code duplication and improving code readability & maintainability. Non-technical team members can also participate in the creation of meaningful test scenarios. Wherever applicable, you should use BDD instead of TDD so that you can make the most out of the diverse talent of team members working in the project.
No Need to Mock Everything
Developers often have the habit of mocking function calls while writing unit tests. As a result, they end up testing if..else statements. These tests don’t hold much value because any programming language can be used to correctly implement if..else logic.
Mock only the lowest level dependencies or other I/O operations (e.g. API calls, database calls, etc.). Thus, you can test whether the private methods are correctly implemented.
Consider that you have to write the code of an e-commerce site web page and the user has the facility to calculate a product’s price based on the VAT of the specific product.
In the following function, we get the product’s price by calculating the VAT. The function calls an internal method calculateVATAddition, which calls an API getVATRate. Here, don’t mock the calculateVATAddition function. Only mocking the getVATRate function will work since we don’t have control over the result of this API.
class ProductService {
// Internal method
calculateVATAddition(priceWithoutVAT) {
const vatPercentage = getVATRate(); // external API call -> Mock
const finalprice = priceWithoutVAT * vatPercentage;
return finalprice;
}
//public method
getPrice(productId) {
const desiredProduct = DB.getProduct(productId);
finalPrice = this.calculateVATAddition(desiredProduct.price); // Don't mock this method
return finalPrice;
}
}
Avoid Duplication in Implementation
It is a known fact that code duplication impacts code readability and makes the code less maintainable. Here is a sample example to demonstrate the same:
if($.browser.chrome) {
console.log(“Browser is Chrome”);
} else if ($.browser.mozilla) {
console.log(“Browser is Firefox”);
} else if ($.browser.msie) {
console.log(“Browser is IE”);
} else {
console.log(“Browser is unknown”);
}
Here is the overall purpose of the implementation:
-
Check the browser on which you are running the page
-
Print the browser in Console
-
If the browser is not among the listed 3, the code prints Browser is unknown in the console
Let’s check a few tests written for this code.
escribe("Browser", function(){
it("should print Browser is Chrome", function(){
expect($.browser.chrome) is true;
});
it("should print Browser is Firefox", function(){
expect($.browser.mozilla) is true;
});
it("should print Browser is IE", function(){
expect($.browser.msie) is true;
});
it("should print Browser is Unknown", function(){
expect($.browser.chrome) is false;
});
it("should print Browser is Unknown", function(){
expect($.browser.mozilla) is false;
});
it("should print Browser is Unknown", function(){
expect($.browser.msie) is false;
});
});
As you can see, there are a lot of repetitive tests. The code is a copy of the implementation, and it misses the proper logic.
For example, if ($.browser.chrome) is false, but ($.browser.msie) is true, the test may still return a false negative.
We can avoid this by just writing
it("should return the correct browser", function(){
var browsers= 'chrome,mozilla,msie';
expect($.browser.browsers).toEqual(true);
});
Efficiency in Cross Browser Testing
In today’s time, your website is meant to be accessed across multiple devices and browsers. This makes cross browser testing an absolute must for consumer-based software products. Leveraring cross browser testing tools is considered as one of the best practices in JavaScript testing.
To ensure that your website is compatible across all browser:OS combinations, you must include the following practices when performing cross browser tests:
-
Categorize bugs as per the browser dependency, as some bugs occur only across a few browsers. Hence, it is unnecessary to test it across all the possible combinations of browsers and devices, else it would take an endless amount of time in testing. Browser compatibility test matrix should be created to prioritize the browsers and platforms that have to be considered for cross browser testing.
-
Get a clear requirement of the browsers and devices from your customers. Next, check if you need to test the site on any older browser. Internet Explorer is almost dead now but you should still consider it for testing if your target audience is still using IE. In that case, develop and test a separate stylesheet meant for older versions of browsers.
-
Instead of setting up local infrastructure, reduce your testing budget and test at scale by opting for a cloud-based cross browser compatibility testing tool like LambdaTest. It offers parallel testing to accelerate your testing efforts and reduce Time to Market (TTM) by multiple folds.
Create A Test Management Suite
If you are working on a large project, you might have a huge load of test data and scripts. A test management tool will be beneficial because:
-
It helps in reducing the time and effort involved in writing and executing test scripts. AI-powered tools can help write scripts using text prediction
-
It helps in organizing all the information in a single dashboard, along with providing controlled access to the users. The person managing the tool can easily check the progress and monitor performance of the entire team
-
It provides a scalable environment for faster test execution
-
It helps save time by reducing the repetitive work of assigning a bug and updating the process (until the bug is fixed)
-
It provides seamless integration with popular tools like JIRA, GitHub, Slack, etc., thereby enhancing collaboration between different teams.
Also check UnableToSetCookieException As it is thrown when selenium webdriver is not able to set the cookies.
Comply With Data Privacy Regulations
We now have data compliance laws that vary based on your company’s location and the industry that it is operating in. For example, companies operating in the EU have to comply with GDPR whereas US-based companies have to comply with CCPA.
The compliance laws state that you cannot use customer’s (or customer’s) data for testing or marketing purposes. If you fail to comply with data privacy rules, you may face a massive penalty and loss of reputation as well.
To prevent these incidents, carry out frequent test data audits, use a test data compliance suite, and invoke practices like data masking or use of synthetic test data.
Avoid Using Too Many Helpers
Helper libraries can help to simplify complex setup requirements but too much simplification might lead to confusion. This is particularly the case if your team has developers that have less experience with your test suite.
Creating your setup with the helper libraries can be tricky if you require a different setup for completing a test scenario. Developers may even get confused because they won’t know the underlying stuff.
Consider a scenario where a lot of time has to be spent in figuring out what is happening during the setup in a beforeAll or beforeEach hook. This essentially means that the overall setup process is too complex.
You can measure the complexity of your setup by asking a new team member about the internals of your suite. If the team member finds it difficult to explain, it means that your setup needs to be simplified by a huge extent. Apart from that, be mindful while using hooks. Test preparation hooks are meant for tearing down processes to run test cases. Only use them when you want to add behavior for all test cases.
Wrapping it Up
Although JavaScript testing may seem simpler, you can do many things to make the testing experience more efficient and fun. The goal behind implementing these JavaScript testing best practices is to keep your test cases easily readable while requiring less maintenance.
Keep in mind to avoid complex setups and too many layers of abstraction. Along with that, introduce the AAA (Arrange, Act, Assert) pattern or the three-layered architecture. The effort is small and returns a lot of value to your team. Have fun in testing, and do let us know if your team follows any other best practices.
Comments (0)