The hard work of the previous chapters has materialized into a working application we can be proud of. But how can we ensure a painless maintainability in the future? A comprehensive automated testing layer will become our lifeline once our application begins to scale up and we have to mitigate the impact of bugs caused by new functionalities colliding with the already existing ones.
Testing (and more specifically unit testing) is meant to be carried out by the developer as the project is being developed. However, we will cover all the intricacies of testing Angular 2 modules in brief in this chapter, now that the project is in a mature stage.
In this chapter, you will see how to implement testing tools to perform proper unit testing of your application classes and components.
In this chapter we will:
- Look at the importance of testing and, more specifically, unit testing
- Review the different parts of a JavaScript unit test
- Discover Jasmine, our testing framework of choice
- Learn how to set up a unit testing environment with Jasmine and SystemJS
- Build a test spec testing a pipe
- Design unit tests for components, with or without dependencies
- Put our routes to the test
- Implement tests for services, mocking dependencies, and stubs
- Intercept XHR requests and provide mocked responses for refined control
- Discover how to test directives as components with no view
- Introduce other concepts and tools such as Karma, code coverage tools, or E2E testing
What is a unit test? If you're familiar already with unit testing and test-driven development, you can safely skip to the next section. If not, let's say that unit tests are part of an engineering philosophy that takes a stand for efficient and agile development processes by adding an additional layer of automated testing on the code before it is developed. This is the core concept is that each piece of code is delivered with its own test, and both pieces of code are built by the developer who is working on that code. First we design the test against the module we want to deliver, checking the accuracy of its output and behavior. Since the module is still not implemented, the test will fail. Hence, our job is to build the module in such a way that it passes its own test.
Unit testing is quite controversial. While there is a common agreement about how beneficial test-driven development for ensuring code quality and maintenance upon time is, not everybody undertakes unit testing in their daily practice. Why is that? Well, building tests while we develop our code can feel like a burden sometimes, particularly when the test winds up being bigger in size than the piece of functionality it aims to test.
However, the arguments favoring testing outnumber the arguments against it:
- Building tests contributes to better code design. Our code must conform to the test requirements and not the other way around. In that sense, if we try to test an existing piece of code and we find ourselves blocked at some point, chances are that the piece of code we aim to test is not well designed and shows off a convoluted interface that requires some rethinking. On the other hand, building testable modules can help to early detect side effects on other modules.
- Refactoring tested code is the lifeline against introducing bugs in later stages. Any development is meant to evolve with time, and on every refactor the risk of introducing a bug that will only pop up in another part of our application is high. Unit tests are a good way to ensure that we catch bugs in an early stage, either when introducing new features or when updating existing ones.
- Building tests is a good way to document our code APIs and functionalities. And this becomes a priceless resource when someone not acquainted with the codebase takes over the development endeavor.
These are only a few arguments, but you can find countless resources on the web about the benefits of testing your code. If you do not feel convinced yet, give it a try. Otherwise, let's continue with our journey and see the overall form of a test.