Category: Unit Tests

I’ve recently been spending time researching into how to write unit tests for an existing codebase. One thing that keeps coming up in the research I’m doing is how important it is to write testable code from the start, but what is testable code?

Well from the research I’ve been doing I found that to write testable code a good approach is following the SOLID principles.

• S – Single Responsibility Principle
• O – Open/Close Principle
• L –  Liskov Substitution Principle
• I –  Interface Segregation Principle
• D – Dependency Inversion Principle

So what do these principles mean and how do they apply to Angular?

Single Responsibility Principle is where an Object should do one thing and one thing only. For example in a controller or component you might have a function that loads some data, updates a local array then loads some more data from another source and finally displays this data in the UI. Well, that is four different things this one function is doing. To make this more testable it would be better to have one function that loads and returns data. One function that binds data passed into it to a local array, then another function which loads data from the second source and then finally allowing Angulars data binding to bind the data to the UI.

This means that you have only three separate functions, which can all be tested separately. One test to check the first function loads data correctly, a second test to check that the second function binds any data passed into it to the local array and finally the third test to check that the third function loads the data from the second source as expected.

Open/Close Principle is where a class is Open to extension, but Closed to changed. An example could be a function loads and returns some data. Then as the project continues the requirement for that data is changed as it is now ordered alphabetically. So you go back and amend the function to order the returned data after it has loaded. By doing this you’ve broken this principle. What you should really do it add a new function that calls the first function, then takes the returned data and then the second function performs the ordering of the returned data. This way you have two separate functions, both performing smaller tasks and the first function, which is already tested, has not been changed.

To write a function with this principle in mind, it needs to (in this loading data example) be able to return the loaded data and not just simply bind the returned data to a local variable or array. If the load data function returns the data as it loads it, then this allows other functions to take this returned data and extend what can be done with it.

Liskov Substitution Principle is where a class that uses another class, should be able to accept using another class without it knowing the difference. Within Angular, this means a controller or component may be using a service to load data, but the controller/component knows so little about the service that another service could replace the original one, without any changes needed to the controller/component.

This is an extremely important principle for writing testable code because adhering to this means that external services can be mocked in tests in order to write tests for just the function that uses this service. Through the use of mocking we can write tests that test different scenarios to see how our original function handles various responses from the mocked service.

Interface Segregation Principle this is important because it forces you to write smaller interfaces/classes which are easier to mock in tests. For example having a service that does loading data, aggregating data and ordering data, means that you will need to mock all three different functions in order to test something that is just using the loading data function. Separating it into three separate services means it is easy to mock just the one you need in order to test your code.

Dependency Inversion Principle is where your concretions (the act or process of concreting or becoming substantial; coalescence; solidification) or classes that are set out. Should only depend on classes that are abstractions of functionality. This means if you have a class that does something, like filtering an array. Then anything other classes it needs in order to perform this filtering should be an abstraction of the implementation. For example, with your class/function that filters an array, you may use something like Underscore or  Lodash to help with the filtering. When you use Underscore or Lodash’s function you aren’t using the inner workings of the library, but an exposed function that abstracts away the inner workings of the library. So if in a new version of the library the helper function you are using is re-written to make it faster, as far as you are concerned you are still calling the helper function in the same way.

So by writing your code using this principle, you are writing more loosely coupled code, which is easier to test, because you test the individual parts. Parts that know nothing or need to know nothing about the inner workings of each other. This makes mocking for tests easier to do.

Following these principles will help make your code more modular, separated and therefore easier to mock for the tests you are going to write. From the research I’ve been doing the main concept to get in order to write more testable code is, in isolation, meaning writing code that can run in isolation is easier to test. It is easier to mock any dependencies (which there shouldn’t be many) it’s easier to write tests just for that single piece of code. Therefore writing more and more tests leads to an application which has more test coverage going forward.

Here are some links to articles, blog posts I’ve found during my research:

• The Principle of OOD
• Unit Test, How to Write Testable Code, and Why it matters
• Answer to a question on Stackoverflow
• Writing Testable Code
• Angular Docs section on Testing

I recently finished reading through an article on Unit Testing in Angular. The article was from the Infragistics website and in 3 parts it tried to demystify Unit Tests in Angular:

• Part 1
• Part 2
• Part 3

In this article, the author, Jared Fineman, really goes into how to setup your tests, how to structure tests and some of the great new features of Angular, that help with testing. One great point Jared makes is *In the world of development, unit tests have long been viewed as second-class citizens. * This is very true, it is something I have been guilty of too, forgetting that Unit Tests are an extremely important part of the development process. As part of my drive this year to improve the quality of my work, I’m focusing on both Unit Testing and readability, so I need to make writing test a core part of my development process.

In the first part of the article, Jared shows how to set up tests for your project. Though at the time of writing this version 6 of Angular was not released yet. So there is a section about updating the .angular-cli.json file, which has now been replaced by the angular.json file. Then in the other two parts of the article, Jared goes through structuring unit tests and some of the great features that Angular has that allow you to really explore the inner workings of your components. So you can write tests that examine all parts of the component.

The one that struck me in the second part of this article was the approach he mentions for structuring your unit tests. He mentions this AAA approach, which stands for Arrange, Act and Assert. The idea is that you first setup everything needed to run the component that is going to be tested, you basically arrange all the parts needed for the component. This could be modules that need to initialised, other parent components or mock data.
Next is the Act section, this is where you call the method or the component to be tested and from that call, the result can be examined. Finally, there is the Assert phase, where our assertions or expectations are tested.

This AAA methodology is great for learning how to set up tests, it is definitely something that isn’t documented enough in the official Angular docs. If a developer is new to Angular and they want to start writing tests for their app, the Angular docs do give a detailed overview of how to write a test for different scenarios. The new Angular docs really give a lot of examples, how to test components, how to test the DOM, how to test services and providers, but the theory of unit testing is not discussed enough in the documentation (but the Angular docs is open source, so maybe that can be changed).

There is, of course, articles about AAA outside of Angular, here are a few I found, though they are C# based the theory still applies:

• Unit Test Basics
• The Fundamentals of Unit Testing: Arrange, Act and Assert
• Arrange Act Assert – Telerik Documentation

There are a lot of articles about the Theory of Unit Testing, just not all Angular specific. It is worth searching around for them. This article from Jared Fineman is a great start.