Tests are important. In our AngularJS applications we have tons of stuff to test, we have unit tests on components, filters, directives and other AngularJS features, we have tests on templates and we also have tests on routes. Most sophisticated AngularJS applications might contain more than one page to display, so you need to have a routing mechanism to navigate to different components in the application.
The thing is how you test this? How you test your routed components? How you test the template with the routing directives?
That is exactly what I am going to talk about in this post. I prefer the AngularUI-Router, because it is really powerful, so this post will contain examples using this framework.
All the goodies that you are building need to be of highest quality. But how is quality possible when no tests are in place?
If you have followed along, this very website promotes test driven development, very passionately if you ask me. I want my code to be thoroughly tested, I want confidence, I want speed. Remember, test driven development is the practice that makes you agile, in terms of speedy development and ability to cope with the code’s evolution. You go faster when you write tests.
That is no different when we code real time applications, in this particular instance, with socket.io, which heavily relies on an event driven style. We need to make sure that our channels, our business rules and the wiring work properly and that is exactly the story that I am going to tell you, so let’s dive in.
Karma is an awesome testing environment, it is open source, it supports a plethora of testing frameworks and it is easy to use.
In this post I am going to create some simple tests, run them on Karma using Jasmine and finally, show some code coverage reports, through Karma coverage.
This post continues from earlier article on Unit testing and code coverage for ASP.NET Web API (1/2).
Much about the topic is inspired from the truly magnificent book “The Clean Coder: A Code of Conduct for Professional Programmers” of Robert C. Martin Series, which of course, I definitely recommend.
Specifying the low level architecture
Professional software developers always test their code. It is part of our daily job, we should be proud and flexible on writing tests. It is a proof that our code actually follows our intent, at least on system’s low level. There are many more tests to be followed, composing a testing strategy, but this post is going to focus solely on one aspect of such strategy, the unit tests.
Let’s say we have the following, one class named
Implementor which has an
DoWork of the class, we call the interface’s method, but we also call another method, which comes by casting the dependency to a derived interface.
All, good, we go ahead and create a unit test project, adding the Moq package as well, in order to mock dependencies.