This post aims to answer a simple question, which is, indeed, its title: “Which tools are used for unit testing in Angular?”
I bet most people when they hear this question immediately answer “Jasmine and Karma,” and that makes sense. After all, these are the default tools installed along with Angular CLI, so they represent the path of least resistance. But as this post will show you, there is life after these two tools. Also, testing tools might include much more than testing frameworks and runners. Things like mocking libraries and code coverage tools are also important.
We start with the basics. We offer overviews of both Angular and the practice of unit testing. Arguably, if you’re here for Angular unit testing tools, you’re already familiar with the framework and the concept of this type of testing. If that’s your case, feel free to skip those sections. Otherwise, reading them will provide you valuable information.
After that, we proceed to the main part of the article, in which we’ll cover the main tools you’re likely to use when unit testing your Angular apps. We start with tools that can be categorized as test frameworks and test runners, with some belonging to the two groups. After that, we cover several miscellaneous tools. Let’s begin.
A Brief Overview of Angular
As promised, we start with a brief overview of the Angular framework.
When the time came for the second version of the framework, the team decided to do a complete rewrite. The result presented some drastic changes to the first version. To avoid confusion, they settled on a change of nomenclature. AngularJS would be used for the 1.x versions and “Angular” for versions from 2 up.
AngularJS continues to be supported to this day. It entered a three-year LTS (Long Term Support) period starting in 2018, which means it’s guaranteed to receive bugfixes until 2021. For new development, the recommended framework is Angular.
Unit Testing: What It Is and Why Should You Care
We’ll now turn our focus to unit testing itself: what it is and why it matters.
It Was About Time We Used Automation to Our Benefit
Let’s first consider the power of automation. We, software developers, literally make a living out of it. We apply automation in order to make all kinds of processes more efficient. By why don’t we use automation to make the software development process itself more efficient?
Until relatively recently, we didn’t. At least, not to the extent we do today. But in recent years, this has changed. Now we see techniques and processes such as Continuous Integration, DevOps, and similar becoming commonplace. When it comes to software testing, this trend manifests itself in the form of automated testing.
Automated Testing for the Win
Automated testing is essential to the modern software development process. And why is that? In short, testing applications manually is too slow and error-prone. It gets in the way of a full (or mostly) automated pipeline.
The other side of the coin has to do with software itself, which is very susceptible to regressions. That means that whenever you make a change to an application, you could inadvertently cause harm to any other part of the codebase. So, the only way to have a high degree of confidence when releasing an application is to thoroughly retest it after each change, no matter how small it is. Since doing so manually would be laughably impractical, resorting to automated testing is a must.
Unit Testing: A Developer Confidence Boosting Tool
We’ve already established that software is particularly susceptible to regressions. So, it logically follows that developers might live in a state of fear of touching the code. If every change to the code, no matter how seemingly insignificant it is, can cause an unintended consequence, the rational thing to do is to make as few changes as possible.
In the long run, that leads to lower quality in the codebase, since the developers won’t feel encouraged to do things that are not urgent, but can result in higher quality in the future, such as refactoring.
That’s where unit tests come in handy. They provide a safety net for developers, allowing them to fearlessly change code, knowing that the tests will fail if they break anything. Since unit tests (ideally) don’t depend on I/O and either don’t cause neither consume side effects, they’re fast, which encourages developers to run them more often.
Angular Unit Testing Tools
Now we’re down to the meat of the article. We’re going to walk you through some of the main tools used for unit testing Angular applications. The tools are categorized into three groups. First, we’ll cover test frameworks. Then we talk about test runners. Finally, we wrap-up by covering miscellaneous tools. Let’s do it!
We’re now going to cover some miscellaneous tools, that are neither test framework nor test runners, but that you’re likely to use when unit testing your Angular apps.
Another important component of a great unit testing strategy is mocking tools. True unit tests shouldn’t have external dependencies, so you should use fakes (mocks/stubs) in order to simulate those dependencies. In the case of Angular, we can also apply Jasmine for that. More specifically, a feature of Jasmine called spies.
In recent years, unit testing’s popularity has really skyrocketed. No, we’re not yet living that ideal scenario where every developer unit tests their code. But we’re making progress. Not that long ago, even the notion of automated tests—of any kind—would be alien for a sizable portion of developers. Nowadays, many developers routinely write unit tests—and other types of tests—along with their production code. And many who don’t wish they did.
In this post, we’ve covered the former. Specifically, we’ve talked about tools used for unit testing in Angular. Most people think immediately in Jasmine and Karma, but they’re not the only tools you should be aware of when it comes to Angular unit testing. In the post, we’ve covered tools that compete with those and can be used in their place. We’ve also covered additional, miscellaneous tools, that aren’t test runners or frameworks but are also important pieces in the unit testing puzzle.
That’s it for today. Thanks for reading, and until next time.