Each day we develop more and more web apps where the source code is 80% JavaScript. The Server side component becomes a mere data service, usually a simple RESTful service. The amount of classes and logic in the Client side is getting larger, and more complex each time, and evidently they are more likely to fail with each update of the code.
To decrease the possibility of failures in our applications there is a paradigm called Test-driven development, based on unit tests.
I believe that, nowadays, all developers have heard something about Unit Testing (UT). If this is your first time then you could start by reading some of the following links:
It is very likely that you are among those who have used Unit Tests while developing in the server side, but I’d bet you have never used Unit Tests in the Client side of your applications, specifically in Javascript and AngularJS.
Right?
If so, don’t worry, here I'll try to introduce you to this fascinating world.
The tools for UT are widespread in the Server side, either in .Net or Java you can find solutions. IDEs like Visual Studio, Eclipse and others, integrate perfectly with the Unit Testing tools and facilitate the creation and execution of Unit Tests.
But what’s happening on the other side of the fence?
This is a question that I‘ve been wondering for a long time. I confess I tried to read about this a couple of years ago and I finished a little bit disappointed. At least where I read, the generalized comments were about projects that have been abandoned, and I couldn’t find anything else interesting enough.
I think these projects were not receiving the required attention, perhaps for a cost problem, perhaps because almost everybody was doing well without using Unit Testing on Javascript, or simply perhaps because still the predominating applications had more than 70% of their source code in the Server side.
But personally, I am having a strong feeling that the development cycle is incomplete, it's like having a table with only three legs.
You can argue that so far, the table is working fine with only three legs...
And yes, it's true, but nobody will deny that supporting the table with four legs will give it more support and will make it stronger.
Observing the development of Angular during the last year I have begun to note that many of their code's examples are making use of unit testing. I went again over the subject and I'm greatly surprised.
The Unit Testing tools for Javascript and Angular have evolved very much, they are as flexible and powerful as their counterparts in the Server side. Even more, there are managers of projects and dependencies for the Client side with the same style of Maven and Gradle for the Server side.
Some of the main tools are:
However, we can create unit tests without any of the tools mentioned above. We can use one of the more evolved frameworks nowadays: Jasmine.
Jasmine is a powerful and flexible framework for unit tests in Javascript with as much or more flexibility than any of the ones that we use on the Server side. It has a very simple and intuitive syntax.
I can remember at least two or three recent projects where I’ve had to build a sort of "hand made" page to test the Angular components, either services or controllers. Well, not anymore, this is past history.
There is a "seed" project in GitHub, ready to be used, including many of these tools pre-configured. In all honesty I think that, despite the facilities offered by this project, it’s too heavy and might not fit your development environment.
I actually prefer to use a pure and clean version of Jasmine. I was looking in GitHub for a cleaner boilerplate project but I haven't really found one containing exactly what I want, or maybe I got tired of looking. So, I have created a basic project containing only the required Jasmine's libraries and a couple of examples with Unit Test for Javascript and Angular. https://github.com/deisbel/angular-jasmine-standalone-seed
What are the most important elements of Jasmine that we need to use? - Only a few:
- A copy of the jasmine-standalone libraries.
This translates to just download the libraries from the Jasmine website and add them to the project's root folder.
- Create unit tests.
This is just writing tests using the Jasmine "language" and saving them in a file with extension .js. You can save these files mixed among others belonging to your app's source code or in a separate folder in the project's root folder.
- Add a simple html page in charge of running the tests, by default named SpecRunner.html.
Requesting the page from any browser is all you need to do to see the results. This page should be updated to add a reference to each test file that you have created and you want to run.
- If you also want to test components of your application defined in Angular (such as Services, Filters, and Controllers) you also must add references to angular and angular-mock libraries.
To show how simple is to write a file to create a test we will use the following Person class, serving us as target for our unit tests.
We are going to create three simple tests to verify that the Person's properties are always properly instantiated, and also, to ensure that the full name of the person is correctly created. These tests are pretty simple, but good enough for our purpose: illustrating how easy can be the process.
How should we define our SpecRunner.html file to execute all of these test?
It should look like this:
So far, I've shown you the less complex cases, only for a pure Javascript class, but how can I create unit tests for my Angular app components?
It's enough by adding a couple more references to our SpecRunner.html page, one for angular.js and another for angular-mocks.js.
Also, you can see that we added two more references, one for the file where an Angular controller is defined and another for the file where the unit tests for that controller are created. The content for each file is below:
If you refresh the SpecRunner.html page to execute again the tests you will see these results:
You can add more files containing classes and tests as you need them.
After reading this article you don’t have any more excuses to ignore unit testing in the Client side, and we can finally add the fourth leg to our table, achieving more reliable apps, happier users and clients.
To deepen in the topic I give you the main links:
