Comparison of JavaScript test tools

When writing JS code, a validation tool can help me avoid stupid mistakes. Although I have many years of experience, I still have variable naming incorrect, resulting in syntax errors, and forgetting to handle errors correctly. A good calibration tool or validator can tell me these questions before I waste my time, especially when it's customer time. A good checksum tool ensures that a project follows code specifications.

There are four JS validators that you can use, but how do you choose which one to use? Next let's look at the characteristics, advantages and disadvantages of these four popular schemes: JSLint, Jshint, Jscs, Eslint.

Overview

Four tools work in the same basic way. They all have a set of user analysis, report JS file error rules. They can all be installed through NPM. They can all be used by the command line, as Grunt plug-ins, and can be integrated into the editor. All four of them support using annotations for configuration.

But the similarity is over. Each tool has its own advantages and disadvantages – The advantages are obtained by comparison.

JSLint

JSLint is one of the oldest tools. In 2002 Douglas Crockford developed the tool and, based on its experience, forced the use of the pristine part of the JS language. If you agree with these pristine things, jslint can be a good tool.

The disadvantage of jslint is that it cannot be configured and expanded. You can't even cut off the need for features, and a lot of missing documents. Official documents are very unfriendly, such as the lack of information on how to integrate them into the editing.

Advantages

• Parameter configuration complete, can be directly used

Disadvantages

• JSLint There is no configuration file, there is a problem if you want to change the parameter settings
• Limited configuration options, many rules cannot be banned
• No personalization rules can be added
• No rules for document logging
• It's hard to figure out which rule caused the mistake.

Jshint

As a configurable version of JSLint, Jshint was developed. You can configure each rule and place it in a configuration file, which is easy to use in large projects. Jshint has good documentation for each rule, so you can know exactly how each rule works. It is also easy to integrate them into the editor.

A small disadvantage of jshint is the loose default configuration inside. That is, you must start it before making it available. It is more difficult to determine which rule users turn on or off error messages than Eslint. Jshint

Advantages

• Most of the parameters can be configured
• Support configuration files, easy to use in large projects
• Need class libraries have been supported, such as jquery, Qunit, Nodejs, mocha, etc.
• Support for basic ES6

Disadvantages

• It's hard to know which rule produces an error
• There are two types of options: Force options and loose options. Makes configuration a bit confusing
• Custom rules are not supported

Jscs

Jscs differs from others because if you do not give it a configuration file or tell it a configuration item, Jscs
Won't do anything. Can save their site now configure items, so this is not a big problem, and there are many configuration items, such as jquery code style configuration items, Google configuration items.

It has more than 90 different rules, and you can create custom rules by using Plug-ins. When integration with other tools requires a specific format, Jscs also supports custom reporting, making it very easy.

Jscs is a code style checker. This means that it only matches the problem of the code format and does not match the potential bugs, errors. As a result, there is a lack of flexibility compared to other tools, but Jscs is also a good tool if you just force the code style to be checked.

Advantages

• Support for custom reporting and easier integration with other tools
• If you follow an available code style, configuration items and prepared configuration files make it easy to start
• There are tags in the report that contain rule names, so it is easy to point out which rule caused the error
• Expand by Customizing Plug-ins

Disadvantages

• Just check the code-style issues. Jscs does not check for potential bugs, such as inapplicable variables, accidental global variables, etc.
• The slowest of the four tools, but not a problem in use

Eslint

Eslint is the newest tool. It is designed to be easy to expand, has a large number of custom rules, easy to install through Plug-ins. It gives the exact output and includes the rule name so that you know which rule is causing the error.

Eslint documents are somewhat confusing. Rules are easy to find and are divided into logical groups, but the configuration guide is easy to confuse in some places. It can, however, provide links in one place to edit integrations, plug-ins, and examples.

Advantages

• Flexibility: Any rule can open the closure, and some rules have some extra configuration
• Easy to expand and have the necessary plugins available
• Easy to understand output
• Contains rules that are not available in other inspectors, making eslint more useful in error checking
• Support for ES6, the only tool to support JSX
• Support for custom reports

Disadvantages

• Requires some configuration
• Slow but not the main problem

My recommendation

My choice is eslint. Jshint is strict and not configurable, while Jshint lacks the extension mechanism. Jscs If just for code-style testing is a good choice, eslint not only can do code-style testing, but it can also check bugs and other problems in your code.

If using Es6,eslint is also an obvious choice. Of the tools mentioned above, eslint the most extensive support for ES6.

If you are like trying eslint, I have created a 5 step Quick start Guide. You can download the Eslint 5-step QuickStart Guide form my website

Jshint is the second choice. If you do not need to eslint advanced features, Jshint once configured can capture the need for good problems. Jscs, with many rules, would be a good choice if there were no other checks outside of the code style.

I am very hesitant to recommend JSLint. Other tools do the same thing, but do not force users to follow these rules. The only exception is that you happen to be unifying those mandatory rules, which is worth studying in depth.

A test tool is a good step to capturing a problem, but it can only see the error of its rules. For further bugs to be automatically captured, I recommend using unit tests. Code view also helps to achieve that goal.

How do you and your team protect the quality of your code?