{"componentChunkName":"component---src-templates-blog-post-js","path":"/snapshot-testing-angular-applications/","result":{"data":{"site":{"siteMetadata":{"title":"Fabrizio Fortunato","author":"Fabrizio Fortunato","siteUrl":"https://izifortune.com"}},"markdownRemark":{"id":"bf864f86-a192-5d8b-a42b-3c3c3ebe2134","excerpt":"In one of my previous articles, I’ve explored how we can start unit testing Angular applications with Jest. Now its time to introduce another exciting feature…","html":"

In one of my previous articles, I’ve explored how we can start unit testing Angular applications with Jest. Now its time to introduce another exciting feature that Jest provides us: Snapshot Testing.

\n

Intro

\n

One of the main advantages of using Jest over Karma + Jasmine is the significant decrease in execution time for the unit tests. What if Jest allows us to decrease, not only, execution time but also the actual writing time of a unit test?

\n

Welcome to snapshot testing.

\n

As the name suggests it, snapshot testing takes any serialisable object, create a snapshot and then compare your changes with the previously taken snapshot. Jest support out of the box snapshot testing an example of a simple snapshot test can be the following:

\n
describe('FlightService', () => {\n  it('Should return a list of flights', () => {\n    const flights = FlightService.list();\n    expect(flights).toMatchSnapshot();\n  });\n});
\n

Upon test execution, Jest takes your object, serialise it into a string, save the representation into a file like the following:

\n
// Jest Snapshot v1, https://goo.gl/fbAQLP\n\nexports[`FlightService Should return a list of flights 1`] = `\nArray [\n  Object {\n    \"arrivalDatetime\": \"2018-06-15T21:00:00\",\n    \"departure\": \"DUB\",\n    \"departureDatetime\": \"2018-06-15T17:25:00\",\n    \"destination\": \"WRO\",\n    \"flightNumber\": \"FR153\",\n  },\n  Object {\n    \"arrivalDateteim\": \"2018-06-16T20:35:00\",\n    \"departure\": \"DUB\",\n    \"departureDatetime\": \"2018-06-16T16:30:00\",\n    \"destination\": \"CIA\",\n    \"flightNumber\": \"FR154\",\n  },\n  Object {\n    \"arrivalDatetime\": \"2018-06-15T20:55:00\",\n    \"departure\": \"DUB\",\n    \"departureDatetime\": \"2018-06-18T17:15:00\",\n    \"destination\": \"MAD\",\n    \"flightNumber\": \"FR155\",\n  },\n]\n`;
\n

Any other execution of the test is compared to the current object snapshot with the previous one stored in the file. The whole functionality boils down to string comparison between the two snapshots. While using snapshot testing, Jest compares the current snapshots with the previous version. That’s why it is necessary to commit the snapshots files along with your test files.

\n

When using snapshot testing, we have to get it right the first time. We are creating the gold standard test, and we have to treat it as the most accurate test possible.

\n

When

\n

In the React ecosystem, snapshot testing is recommended primarily for UI components, where you can quickly render components leveraging jsdom.\nSnapshot testing can be used alongside unit testing or in some cases also replace it entirely.\nThe decision is related to the status of your project. If your current project doesn’t much testing coverage than snapshot testing can be a way to increase coverage without any pain; on the other hand, if a project has already a high unit test coverage than you can use it as support testing to perform regression testing.

\n

ng-world

\n

Snapshot testing is not only available in the React world. We can use and apply snapshot testing in an Angular application also.

\n

I assume that your application is already configured for using Jest, if not you can check out my previous article.

\n

An Angular application is a collection of components, directives, services and pipes which combined make a module. Angular makes it easy to test any element of your application, and we can apply snapshot testing to each of those elements.

\n

Component

\n

In an Angular component there are few parts that we can unit test:

\n\n

Snapshot testing can cover all those different parts and at the same time speed up your test creation and coverage.

\n

Let’s take the following FlightInfoComponent used to display informations about a selected flight:

\n
import { Input, Component } from '@angular/core';\n\n@Component({\n  selector: 'flight-info',\n  template: `\n<mat-list-item>\n  <div class=\"fare\">\n    <span class=\"airport\">{{ flight.departure }}</span>\n    <small>{{ flight.departureDatetime | date:'short' }}</small>\n  </div>\n  <div class=\"fare\"> \n    <span class=\"airport\">{{ flight.destination }}</span>\n    <small>{{ flight.arrivalDatetime | date:'short' }}</small>\n  </div>\n</mat-list-item>\n  `,\n  styleUrls: [ './flight-info.component.css' ]\n})\nexport class FlightInfoComponent  {\n  @Input() flight;\n}
\n

The FlightInfoComponent is a dumb component, it doesn’t hold any logic, and its only concern is displaying information received as @Input. What is necessary to test here is that the information is displayed correctly, like a pure function, given a specific input we are expecting the same output.

\n

Snapshot testing shines in this scenarios. The component fixture is a serialisable object; therefore, we can snapshot it.

\n
it('Should display a flight', () => {\n  const fixture = TestBed.createComponent(FlightInfoComponent);\n  expect(fixture).toMatchSnapshot();\n});
\n

We can now pass data as @Input for FlightInfoComponent and generate a snapshot that ensures our component UI is predictable.

\n
  it('Should display a flight from DUB to WRO', () => {\n    component.flight = {\n      flightNumber: 'FR153',\n      departure: 'DUB',\n      destination: 'WRO',\n      departureDatetime: '2018-06-15T17:25:00',\n      arrivalDatetime: '2018-06-15T21:00:00'\n    };\n    fixture.detectChanges();\n    expect(fixture).toMatchSnapshot();\n  });
\n

The snapshot created will be the following:

\n
exports[`FlightInfoComponent Should display a flight from DUB to WRO 1`] = `\n<flight-info\n  flight={[Function Object]}\n>\n  <mat-list-item\n    class=\"mat-list-item\"\n  >\n    <div\n      class=\"mat-list-item-content\"\n    >\n      <div\n        class=\"mat-list-item-ripple mat-ripple\"\n        mat-ripple=\"\"\n        ng-reflect-disabled=\"true\"\n        ng-reflect-trigger=\"[object HTMLUnknownElement]\"\n      />\n      <div\n        class=\"mat-list-text\"\n      />\n      <div\n        class=\"fare\"\n      >\n        <span\n          class=\"airport\"\n        >\n          DUB\n        </span>\n        <small>\n          6/15/18, 5:25 PM\n        </small>\n      </div>\n      <div\n        class=\"fare\"\n      >\n        <span\n          class=\"airport\"\n        >\n          WRO\n        </span>\n        <small>\n          6/15/18, 9:00 PM\n        </small>\n      </div>\n    </div>\n  </mat-list-item>\n</flight-info>\n`;
\n

We can notice that the template of our component is rendered correctly, displaying the information about our flight.

\n

Service/Pipe

\n

After components, we can apply snapshot testing to services and pipes. The concept is the same that we use for components with the exception that we can omit TestBed. Services and pipes are javascript classes and TestBed is only used for handling the dependencies, which can be easily mocked, for unit tests, when invoking the constructor of such classes.

\n

I’m grouping services and pipes because the approach to testing is the same.

\n

Let’s define our FlightListService:

\n
import { Injectable } from '@angular/core';\n\n@Injectable()\nexport class FlightListService {\n  public list() {\n    return [\n      { flightNumber: 'FR153', departure: 'DUB', destination: 'WRO', departureDatetime: '2018-06-15T17:25:00', arrivalDatetime: '2018-06-15T21:00:00' },\n      { flightNumber: 'FR153', departure: 'WRO', destination: 'DUB', departureDatetime: '2018-06-15T21:25:00', arrivalDatetime: '2018-06-15T23:05:00' },\n      { flightNumber: 'FR154', departure: 'DUB', destination: 'CIA', departureDatetime: '2018-06-16T16:30:00', arrivalDatetime: '2018-06-16T20:35:00' },\n      { flightNumber: 'FR154', departure: 'CIA', destination: 'DUB', departureDatetime: '2018-06-16T21:00:00', arrivalDatetime: '2018-06-16T23:15:00' },\n      { flightNumber: 'FR155', departure: 'DUB', destination: 'MAD', departureDatetime: '2018-06-18T17:15:00', arrivalDatetime: '2018-06-15T20:55:00' },\n      { flightNumber: 'FR155', departure: 'MAD', destination: 'DUB', departureDatetime: '2018-06-18T21:30:00', arrivalDatetime: '2018-06-15T23:10:00' },\n    ]; \n  }\n\n  public single(departure, destination) {\n    const flight = this.list()\n    .filter(el =>\n      (el.departure === departure &&\n        el.destination === destination)\n    );\n    return flight ? flight[0] : undefined;\n  }\n}
\n

So now start testing one of the public methods available in the service.

\n
import { FlightListService } from './FlightListService';\n\ndescribe('FlightListService', () => {\n  let service;\n\n  beforeEach(() => {  \n    service = new FlightListService();\n  });\n\n  it('Should return a single fligth', () => {\n    expect(service.single('DUB', 'MAD')).toMatchSnapshot();\n  })\n})
\n

In a real-world application the FlightListService, rather than returning a hardcoded list of flights, will contact an API to get the list of all the available flights.

\n

Our list method can be rewritten as follows:

\n
public listAPI() {\n  return this.$http.get(\n      'https://murmuring-ocean-10826.herokuapp.com/en/api/2/flights/from/DUB/to/STN/2014-12-02/2015-02-02/250/unique/?limit=15&offset-0'\n  );\n}
\n

There are two choices now for testing the list method. We can proceed to mock the HTTP call and returned some values during the test. Alternatively, another option is to continue doing the HTTP call and get the value directly from a real service.

\n

Choosing the first option let the test fall into unit tests since we are testing the method in isolation. We can easily mock dependencies by using jest mock functions

\n
describe('FlightListService', () => {\n  let service;\n  const http = {  \n    get: jest.fn()\n  };\n\n  beforeEach(() => {\n    service = new FlightListService(\n      http as any\n    );\n  });\n\n  it('Should return all the routes from API', () => {\n    expect(service.listAPI()).toMatchSnapshot();\n  });\n});
\n

The previous test, using mocking values, doesn’t add much value to our test suite. We are testing a tautology, given that we are not doing anything with the data returned.

\n

The second option that we have is to use snapshot testing for integration tests. We are testing functionality spanning across multiple units. We cannot mock HttpClient now since we want our test make the actual API call.

\n
import { TestBed } from '@angular/core/testing';\nimport { HttpClientModule } from '@angular/common/http';\n\nimport { FlightListService } from './flight-list.service';\n\ndescribe('FlightListService Integration tests', () => {\n  let service: FlightListService;\n\n  beforeEach(() => {\n    TestBed.configureTestingModule({\n      imports: [HttpClientModule],\n      providers: [FlightListService]\n    });\n\n    service = TestBed.get(FlightListService);\n  });\n\n  it('Should return all the routes from API', done => {\n    service.listAPI().subscribe(res => {\n      expect(res).toMatchSnapshot();\n      done();\n    });\n  });\n});
\n

The integration test checks that the API is not changing or breaking the contract of the response, giving our application an extra safety measure especially when you are not in control of the API.

\n

NGRX

\n

If you are developing a medium/big Angular application chances are that you are using NGRX for managing your state. By convention, the top-level state is an object or some other key-value collection like a Map, but technically it can be any type. Still, you should do your best to keep the state serialisable. Don’t put anything inside it that you can’t easily turn into JSON.

\n

The previous is an extract from reduxjs documentation. The state in redux is a serialisable object that we can test using snapshot testing.

\n

Let’s take the common counter reducer example and apply snapshot test to it.

\n
export const counter: ActionReducer<number> = (state: number = 0, action: Action) => {\n    switch(action.type){\n        case 'INCREMENT':\n            return state + 1;\n        case 'DECREMENT':\n            return state - 1;\n        default:\n            return state;\n    }\n};
\n
import {counter} from \"./counter\";\n\ndescribe('The counter reducer', () => {\n  it('should return current state when an invalid action is dispatched', () => {\n      const actual = counter(0, {type: 'INVALID_ACTION'});\n      expect(actual).toMatchSnapshot();\n  });\n\n  ...\n});
\n

snapshot failed

\n

Testing, in general, improve the quality of our application and let us feel more comfortable while making new changes, that we are not breaking any existing functionality. We write tests because our application changes over time and we want to make sure that we don’t break previous functionalities.

\n

We have explored how to create snapshots for different elements of our Angular application what is missing now is how to update the snapshots if something has changed in our code.\nThere is a command:

\n
npm run jest -- -u
\n

The command updates all the snapshots to the current version of your objects, ignoring and discarding the previous one. Don’t forget to commit once again the updated snapshots.

\n

You can find all the examples used in the article in\nhttps://stackblitz.com/edit/angular-snapshot-testing feel free to clone it and start exploring snapshot testing.

","frontmatter":{"title":"Snapshot testing Angular applications","date":"July 02, 2018","description":null,"socialImage":{"childImageSharp":{"fixed":{"src":"/dist/static/88fc993698200a96f2782641532f8e54/048fd/jest-angular-3.png"}}},"image":{"childImageSharp":{"fluid":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAHCAIAAACHqfpvAAAACXBIWXMAAAsSAAALEgHS3X78AAAA6ElEQVQY02PQLT+OhvRLjwbGr5hoXLSPxapPPirCd6pJ8UFMZUDEgKKt7KhK7flOy4qnDBovOQ0fWMVfMw67puI5RyJQr4Kg5tKjynUXus3LXjBo3BZweJzSdLNswmVVrwWi3jqVJ4nQXH+h0LH9paTzy7SWlw0z7jbOvK4f1K0cr1F3Xq/sGCHNDRcTvCd/UPV8WTzhjl3SGfesu/r+jXqZSo1X9EuP4NMMNFuj+oxT6qYTCkEfLaLv6wSfE7U9wKQXEzRDtfY80Gh8miH6NatOm+bt7bSuOshp260S75y2EWgippuBCAA+FcIU366YUwAAAABJRU5ErkJggg==","aspectRatio":2.737704918032787,"src":"/dist/static/2d5de7a09e3e1bf6c4feaa5eb6864a47/a5924/jest-angular-4.png","srcSet":"/dist/static/2d5de7a09e3e1bf6c4feaa5eb6864a47/17cc0/jest-angular-4.png 167w,\n/dist/static/2d5de7a09e3e1bf6c4feaa5eb6864a47/f7869/jest-angular-4.png 333w,\n/dist/static/2d5de7a09e3e1bf6c4feaa5eb6864a47/a5924/jest-angular-4.png 666w","sizes":"(max-width: 666px) 100vw, 666px"}}}}}},"pageContext":{"slug":"/snapshot-testing-angular-applications/","previous":{"fields":{"slug":"/performance-budgets-with-lighthouse-lighthouse-keeper/"},"frontmatter":{"title":"Performance budgets with Lighthouse - Lighthouse keeper"}},"next":{"fields":{"slug":"/angular-polyfill-strategies/"},"frontmatter":{"title":"Angular polyfill strategies"}}}}}