Liquid samples in a laboratory. Cover photo by Louis Reed on Unsplash.
Original publication date: 2018-11-19.
To test a container component, we will go through tactics for testing RxJS observables and application state commands since these are used to implement the two main purposes of container components:
- Container components supply a data flow for presentation.
- Container components translate component-specific events to application state commands — or actions to put it in Redux/NgRx Store terms.
Container component templates are hardly worth testing, since they only contain data bindings. Because of this, we can opt out of Angular testing modules for faster unit tests.
Many terms used in this article are explained in the introductory article “Model-View-Presenter with Angular”.
Container components are built specifically to bind data to presentational components. Because of this, we immediately know the number and types of observable properties and methods that our container components need.
In the article “Container components with Angular”, we extracted the
HeroesContainerComponent from a mixed component.
To bind to the presentational heroes component,
- An observable property that emits all heroes
- A method that adds a hero
- A method that deletes a hero
Our container component delegates to a
HeroService for commands and queries against the application state and persistence layers. In TypeScript, a type of
HeroService does not mean that it has to be an instance of the
HeroService class. We only need to pass an object that has the same interface, meaning methods and properties of the same signature as the hero service class.
Read an example of how types in TypeScript can be sneaky, especially for developers used to developing in mainstream C-family object-oriented programming languages such as C# and Java.
The hero service has quite a large interface with 7 public methods. Since it is very unlikely that a single component will need all of the service methods, it is in violation of the Interface Segregation Principle — part of the SOLID principles by Robert “Uncle Bob” Martin. There are ways to address this issue but we will leave that for another time.
Instead, we will create a hero service stub with only the methods we need, so an object with methods that return data in the shape that we want. By doing this, we avoid testing a service in a unit test suite that is only meant to test the component in isolation.
Notice that we use the
asapScheduler when creating observables from arrays to make sure that values are emitted asynchronously as in a real world scenario. Failing to do so can hide edge cases — mostly in integration tests or when testing with the Angular
TestBed. We’ll follow best practices to prevent any errors.
Read more about the importance of RxJS schedulers when testing in “Testing Observables in Angular” by Netanel Basal.
When testing a container component, we can leave out the Angular Compiler from the test suite entirely since a container component has no data binding API. Its template is only for binding to one or more presentational components which means that there is no user interaction involved and no tricky UI logic to test. This means that we can opt out of using the Angular
We will treat the component as a regular class and create instances by passing dependencies to its constructor ourselves. Getting rid of compilation, dependency injection and the component lifecycle means that our unit tests will execute blazingly fast.
The main reason for the increased testing speed is that Angular compiles components for every test case, that is a compilation cycle for every single
it call in a test suite. When the component-under-test has styles and template in separate files as opposed to inline in the
Component decorator, it will add even more to the test execution time. This is because the compiler has to read, parse, and compile multiple files before being able to run the next test case.
We create a Jasmine Spy that will observe the
heroes$ property by subscribing to it. This will make us able to verify what, when and how often data is emitted.
For each test case, we create a container component and subscribe the spy to the
heroes$ property. In the
afterAll hooks, we clean up the subscriptions and subject that we created during the tests.
We stub only the hero service methods that are used by the container component. When adding test cases one at a time, we would have added the spies and stubbed methods when the need occurred in a test case.
We expect the
heroes$ observable to emit all the hero fakes that we have provided to the hero service stub.
In the first test case we expect our spy to have observed a single value being emitted, containing the female Marvel heroes we use as fakes. We also make sure that the heroes are emitted exactly once in the second test case.
The second test case is not really necessary from a testing perspective. We do not care about the specifics of how the container component gets its data. However, in my experience it is valuable to verify that the application state layer has only been queried once to prevent multiple requests to the back-end.
The hero service stub emits the value asynchronously. We use the Angular testing utilities
Angular uses Zone.js to do this neat trick. When calling
tick, microtasks like promises as well as observables that use the
asapScheduler are flushed first. Afterwards, macrotasks are flushed, such as
setInterval operations as well as observables that use
Read short examples explaining schedulers, microtasks and macrotasks in “What are schedulers in RxJS” by Kwinten Pisman.
RxJS has a utility function similar to
fakeSchedulers. It works like the one provided by Angular. However, it currently has the slight disadvantage that it must be imported from a specific sub-package depending on the testing framework that we use. While many Angular projects use Karma and Jasmine just like Tour of Heroes, we might want to keep the option open to change the test runner, testing framework, and test doubles library at a later point in time.
Learn how to fake the progress of time with the solution provided by RxJS in “RxJS: Testing with Fake Time” by Nicholas Jamieson.
We expect the
add method to notify the server in the persistence layer and alter the persistent state. To verify our expectations, we test whether the
heroes$ observable emits the added hero when the server responds.
Our hero service stub is configured to react to the
addHero command by default.
The container component delegates to the hero service when a hero is added. We verify that a partial hero with the specified name is passed as an argument to the hero service method
addHero and that it has only been called once.
This is enough to verify the integration to the persistence layer. It is the hero service’s responsibility to ensure that the server state is updated meaning that the hero service test suite is responsible for verifying this, not the heroes container component test suite.
So far we have verified the delegation to the hero service and the way that the application state is affected when the server responds successfully.
How do we handle server errors, connection loss, and so on? We ignore the add hero command by not emitting the specified hero through the
heroes$ observable. Let us alter the hero service stub and verify this behavior.
When working with an observable, it is important to handle errors that it throws. We use the pessimistic update strategy here to only update the persistent state once the server state update has been confirmed.
We could combine this with a notification to the user when errors occur. We could even prompt them to retry the operation or use an automatic retry strategy to handle temporary connection loss or server downtime.
delete method notifies the persistence layer. This expectation is verified by spying on the
deleteHero method of our stubbed hero service.
The optimistic update strategy is used for hero deletion. The hero is removed immediately from the persistent state. We verify this in another test case.
tick to observe the persistent state change. This tells us that it happens asynchronously, which is fine. We are able to check that the specified hero has been filtered out from the heroes state.
The second part of the optimistic update strategy is that the persistent state must roll back when the server state update fails.
In this final test case, we alter the stubbed hero service to emulate a server timeout after the hero is deleted. We verify that all the heroes are back in the heroes state.
When we test how a container component integrates with application state management, we describe how component-specific events originating from user interactions are translated into commands.
We verify that the resulting commands are sent to services, NgRx action dispatchers, or similar software artifacts. Often, we also verify the exact number of commands sent to prevent expensive side effects or corrupted state.
In addition to verifying that a command is sent, we make assertions about the visible (public) side effects that occur, such as an updated state being emitted through an observable property on a service or a store.
We tested persistence update strategies even though this application state logic belongs in a non-presentational layer such as a service or an NgRx side effect.
To test the data flow supplied by a container component, we verify which data is emitted and the time that it happens. For this purpose, we used stubbed dependencies. We even verified the exact number of queries sent to the dependency to prevent expensive side effects.
Note that we never trigger any lifecycle hooks. In fact, nothing about the container component model or its test suite is Angular-specific.
No side effects occur when our container component instance is constructed. This puts us in full control of the data flow that the container component encapsulates, making it easier to reason about.
All the integration logic that we test would have been more difficult and a lot slower to test through a UI component. This would also not have added any value to the tests.
You can find the full heroes container component test suite on GitHub.
Read the introductory article “Model-View-Presenter with Angular”.
This is also where you will find links to the companion GitHub repository, related articles, and other useful resources.
Are you sick of worrying about state management and back-end stuff in your Angular components? Extract all that nasty non-presentational logic into container components. This is how: "Container components with Angular".
I want to thank you, Max Koretskyi, for helping me get this article into the best shape possible. I greatly appreciate the time you take to share your experiences about writing for the software development community.
Thank you, dear reviewers, for helping me realize this article. Your feedback has been invaluable!