It's important to test. Testing allows us to scale and refactor our code without any difficulty. Many developers follow the test-driven development process. I believe that writing tests can make software development more interesting and often leads to better code. Good design and tested systems are easier to maintain.
In the past few years, developers have begun to put a lot of application logic into the browser, and we are beginning to write more and more JavaScript code. Because the language is very popular, developers are starting to create tools to improve the JavaScript development experience. In this article, we'll talk about some of the tools that are designed to test client JavaScript code.
Test Settings
Let's talk about the types of tools that can be tested, which allow us to build, group, and run our tests.
Test Framework
The framework contains functions such as suite, describe, test, or it. These allow us to create groups of tests that are often referred to as kits (suit). For example:
Describe (' Testing user Management ', function () {
It (' Should register a new user ', function (done) {
The actual testing goes here
});
It (' should remove a user ', function (done) {
The actual testing goes here
});
});
We split the application logic into chunks and each block has its own suite. The kit includes related tests that we want to run on the code. The popular JavaScript test framework has qunit, Jasmine, or Mocha.
declaring Libraries
We use the Declaration library to do the actual checking. They provide easy-to-use functions, such as the following example:
Expect (5). To.be.a (' number ');
There are a lot of modules available for us to use. Node.js even has a built-in module, there are some open source tools for us to choose from, such as Chai, Expect or should.js.
It should be recalled that some of the test frameworks have their own assertion libraries.
The running device
We can either need or may not need a runtime (runner). In some cases a single test framework is not satisfied, so we need to run the test in a specific context. To accomplish this, we use a runtime. In some cases these tools are referred to as "spec runners" or "Test runners." These tools package our test suite and run in a special environment. We're going to talk about that.
Application
We need a test-ready application. Although this is only for illustrative purposes, it cannot be too simplistic. Todomvc seems to be a good choice. It basically uses a lot of different frameworks, just like any other Todo app. We use backbone.js variants. This is what the application looks like:
Let's say this is a project we were working on last month and we're planning to release it next week. We want to make sure that it passes some tests and that the backend has already been tested. The only problem is the client's JavaScript code. At this point, as the application has been completed, we are most interested in whether it works properly. It's a Todo app, so we need to ensure that users can add, delete, and edit tasks.
testing in the browser
We need to perform a check on the code running in the browser, so it's reasonable to test in the browser. We will use Mocha as a framework. Because the framework does not have a assertion library, we will refer to Chai in the project. We downloaded the app from todomvc.com and browsed the file:
├──bower_components
├──js
│├──collections
│├──models
│├──routers
│├──views
│└──app.js
└──bower.json
└──index.html
└──readme.md
This article is about testing, so we're not going to delve into the details of how Backbone.js works. However, here are some basic details of the files and directories:
bower_components– contains backbone.js libraries, local storage assistants, JQuery, underscore.js, and Todomvc Common Files
js– This directory contains the actual code for this app
bower.json– defines the dependencies of the project
index.html– contains HTML tags (templates)
In the normal development process, we open a browser, load the application, and use the UI. We typed some text in the input box. A new Todo, press Enter and the task appears below. By clicking on the small x flag to remove the record, edit the task by double-clicking the TODO. We have a lot of actions involving different mouse events.
To test the app, we don't want to repeat the above steps over and over again. Automated testing can help us. We will be able to run the application effectively and write code that interacts with the page as we do manually. Let's create a Tests_mocha folder to store our tests.
├──bower_components
├──js
│├──collections
│├──models
│├──routers
│├──views
│└──app.js
├──tests_mocha
│├──package.json
│├──spec.js
│└──testrunner.html
└──bower.json
└──