{"id":6927,"date":"2023-01-26T02:19:55","date_gmt":"2023-01-26T01:19:55","guid":{"rendered":"https:\/\/www.angulararchitects.io\/?p=6927"},"modified":"2023-09-04T12:58:09","modified_gmt":"2023-09-04T10:58:09","slug":"testing-angular-standalone-components","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/testing-angular-standalone-components\/","title":{"rendered":"Testing Angular Standalone Components"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 7 of 8 in the series “Angular's Future with Standalone Components”<\/em>\t\t<\/p>\n\t\t\t<\/label>\n\n\t\t\t

\n\t\t\t
    \n\t\t\t\t\t\t\t\t\t
  1. Angular’s Future Without NgModules – Part 1: Lightweight Solutions Using Standalone Components<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  2. Angular’s Future Without NgModules – Part 2: What Does That Mean for Our Architecture?<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  3. 4 Ways to Prepare for Angular’s Upcoming Standalone Components<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  4. Routing and Lazy Loading with Angular’s Standalone Components<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  5. Angular Elements: Web Components with Standalone Components<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  6. The Refurbished HttpClient in Angular 15 – Standalone APIs and Functional Interceptors<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  7. Testing Angular Standalone Components<\/span><\/li>\n\t\t\t\t\t\t\t\t\t
  8. Automatic Migration to Standalone Components in 3 Steps<\/a><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    With Standalone Components, Angular becomes a lot more lightweight: NgModules are optional and hence we can work with lesser indirections. To make this possible, components now refer directly to their dependencies: other components, but also directives and pipes. There are so-called Standalone APIs for configuring services such as the HttpClient<\/code>.<\/p>\n

    Additional Standalone APIs provide mocks for test automation. Here, I'm going to present these APIs. For this, I focus on on-board tools supplied with Angular. The \ud83d\udcc2 examples<\/a> used can be found here<\/a><\/p>\n

    If you don't want to be go with the on-board resources alone, you will find the same examples based on the new Cypress Component Test Runner and on Testing Library in the third-party-testing<\/code> branch.<\/p>\n

    \n

    Big thanks to my colleague and Angular testing expert Rainer Hahnekamp<\/a> who reviewed this article and also provided the mentioned examples using Cypress and the Testing Library.<\/p>\n<\/blockquote>\n

    Test Setup<\/h2>\n

    Even though Standalone Components make modules optional, the TestBed<\/code> still comes with a testing module. It takes care of the test setup and provides all components, directives, pipes, and services for the test:<\/p>\n

    import { provideHttpClient } from '@angular\/common\/http';\nimport { HttpTestingController, provideHttpClientTesting } \n    from '@angular\/common\/http\/testing';\n\n[\u2026]\n\ndescribe('FlightSearchComponent', () => {\n  let component: FlightSearchComponent;\n  let fixture: ComponentFixture<FlightSearchComponent>;\n  beforeEach(async () => {\n\n    await TestBed.configureTestingModule({\n      imports: [ FlightSearchComponent ],\n      providers: [\n        provideHttpClient(),\n        provideHttpClientTesting(),\n\n        provideRouter([]),\n\n        provideStore(),\n        provideState(bookingFeature),\n        provideEffects(BookingEffects),\n      ],\n    })\n    .compileComponents();\n\n    fixture = TestBed.createComponent(FlightSearchComponent);\n    component = fixture.componentInstance;\n    fixture.detectChanges();\n  });\n\n  it('should search for flights', () => { [\u2026] });\n});<\/code><\/pre>\n
    The example shown imports the Standalone Component to be tested and provides the required services via the providers<\/code> array. This is exactly where the mentioned Standalone APIs come into play. They provide the services for the HttpClient<\/code>, the router and NGRX.<\/p>\n
    The provideStore<\/code> function sets up the NGRX store, provideState<\/code> provides a feature slice required for the test and provideEffects<\/code> registers an associated effect. Below we will swap out these constructs for mocks.<\/p>\n
    The provideHttpClientTesting<\/code> method is interesting: it overrides the HttpBackend<\/code> used behind the scenes by the HttpClient<\/code> with an HttpTestingBackend<\/code> that simulates HTTP calls. It should be noted that it must be called after (!) provideHttpClient<\/code>.<\/p>\n
    It is therefore first necessary to set up the HttpClient<\/code> by default in order to then overwrite individual details for testing. This is a pattern we will see again below when testing the router.<\/p>\n
    The HttpClient Mock<\/h2>\n
    Once the HttpClient<\/code> and HttpTestingBackend<\/code> have been set up, the individual tests are implemented as usual: The test uses the HttpTestingController<\/code> to find out about pending HTTP requests and to specify the HTTP responses to be simulated:<\/p>\n
    it('should search for flights', () => {\n  component.from = 'Paris';\n  component.to = 'London';\n  component.search();\n\n  const ctrl = TestBed.inject(HttpTestingController);\n\n  const req = ctrl.expectOne('https:\/\/[\u2026]\/flight?from=Paris&to=London');\n  req.flush([{}, {}, {}]); \/\/ return 3 empty objects as dummy flights\n\n  component.flights$.subscribe(flights => {\n    expect(flights.length).toBe(3);\n  });\n\n  ctrl.verify();\n});<\/code><\/pre>\n
    The test then checks whether the component processed the simulated HTTP response as intended. In the case shown, the test assumes that the component offers the received flights via its flights<\/code> property.<\/p>\n
    At the end, the test ensures that there are no further HTTP requests that have not yet been answered. To do this, it calls the verify<\/code> method provided by the HttpTestingController<\/code>. If there are still open requests at this point, verify<\/code> throws an exception that causes the test to fail.<\/p>\n
    Shallow Testing<\/h2>\n
    If you test a component, all sub-components, directives, and pipes used in the template are automatically tested as well. This is undesirable, especially for unit tests that focus on a single code unit. Also, this behavior slows down test execution when there are many dependencies.<\/p>\n
    Shallow tests are used to prevent this. This means that the test setup replaces all dependencies with mocks. These mocks must have the same interface as the replaced dependencies. In the case of components, this means -- among other things -- that the same properties and events (inputs and outputs) must be offered, but also that the same selectors must be used.<\/p>\n
    The TestBed<\/code> offers the overrideComponent<\/code> method for exchanging these dependencies:<\/p>\n
    await TestBed.configureTestingModule([\u2026])\n  .overrideComponent(FlightSearchComponent, {\n    remove: { imports: [ FlightCardComponent ] },\n    add: { imports: [ FlightCardMock ] }\n  })\n  .compileComponents();<\/code><\/pre>\n
    In the case shown, the FlightSearchComponent<\/code> uses another Standalone Component in its template: the FlightCardComponent<\/code>. Technically, this means that the FlightCardComponent<\/code> appears in the imports<\/code> array of FlightSearchComponent<\/code>. For implementing a shallow Test, this entry is removed. As a replacement, the FlightCardMock<\/code> is added. The remove<\/code> and add<\/code> methods take care of this task.<\/p>\n
    The FlightSearchComponent<\/code> is thus used in the test without real dependencies. Nevertheless, the test can check whether components behave as desired. For example, the following listing checks whether the FlightSearchComponent<\/code> sets up an element named flight-card<\/code> for each flight found.<\/p>\n
    it('should display a flight-card for each found flight', () => {\n  component.from = 'Paris';\n  component.to = 'London';\n  component.search();\n\n  const ctrl = TestBed.inject(HttpTestingController);\n\n  const req = ctrl.expectOne('https:\/\/[\u2026]\/flight?from=Paris&to=London');\n  req.flush([{}, {}, {}]);\n\n  fixture.detectChanges();\n\n  const cards = fixture.debugElement.queryAll(By.css('flight-card'));\n  expect(cards.length).toBe(3);\n});<\/code><\/pre>\n
    More: Professional Angular Testing Workshop (online, interactive, advanced)<\/h3>\n
    Improve your software quality and make your live easier with our Professional Angular Testing Workshop!<\/a>\"\"All Details (English Workshop)<\/a> | All Details (German Workshop)<\/a>
    \n<\/p>\n
    Mock Router and Store<\/h2>\n
    The test setup used so far only simulated the HttpCient<\/code>. However, there are also Standalone APIs for mocking the router and NGRX:<\/p>\n
    import { provideRouter } from '@angular\/router';\nimport { provideLocationMocks } from '@angular\/common\/testing';\n\nimport { provideMockStore } from '@ngrx\/store\/testing';\nimport { provideMockActions } from '@ngrx\/effects\/testing';\n\n[\u2026]\n\ndescribe('FlightSearchComponent (at router level)', () => {\n  let component: FlightSearchComponent;\n  let fixture: ComponentFixture<FlightSearchComponent>;\n  let actions$ = new Subject<Action>();\n\n  beforeEach(async () => {\n    await TestBed.configureTestingModule({\n      providers: [\n        provideHttpClient(),\n        provideHttpClientTesting(),\n\n        provideRouter([\n          { path: 'flight-edit\/:id', component: FlightEditComponent }\n        ]),\n        provideLocationMocks(),\n\n        provideMockStore({\n          initialState: {\n            [BOOKING_FEATURE_KEY]: {\n              flights: [{ id:1 }, { id:2 }, { id:3 }],\n            },\n          },\n        }),\n\n        provideMockActions(() => actions$),\n      ],\n      imports: [FlightSearchComponent],\n    }).compileComponents();\n\n    fixture = TestBed.createComponent(FlightSearchComponent);\n    component = fixture.componentInstance;\n    fixture.detectChanges();\n  });\n\n  [\u2026]\n});<\/code><\/pre>\n
    As with testing the HttpClient<\/code>, the test first sets up the router in the usual way. Then, it uses provideLocationMocks<\/code> to override a couple of internally used services, namely Location<\/code> and LocationStrategy<\/code>. This procedure allows the route change to be simulated in the test cases. The MockStore<\/code> which also ships with NGRX is used instead of the traditional one. It allows the entire content of the store to be freely defined. This is done either by calling provideMockStore<\/code> or via its setState<\/code> method. Also, provideMockActions<\/code> gives us the ability to swap out the actions$<\/code> observable that NGRX effects often rely on. A test case using this setup could look like as follows: <\/p>\n
    it('routes to flight-card', fakeAsync(() => {\n\n  const link = fixture.debugElement.query(By.css('a[class*=btn-default ]'))\n  link.nativeElement.click();\n\n  flush();\n  fixture.detectChanges();\n\n  const location = TestBed.inject(Location);\n  expect(location.path()).toBe('\/flight-edit\/1;showDetails=false')\n\n}));<\/code><\/pre>\n
    This test assumes that the FlightSearchComponent<\/code> displays one link per flight in the (mock)store. It simulates a click on the first link and checks whether the application then switches to the expected route. In order for Angular to process the simulated click and trigger the route change, the change detection must be running. Unfortunately, this is not automatically the case with tests. Instead, it is to be triggered with the detectChanges<\/code> method when required. The operations involved are asynchronous. Hence, fakeAsync<\/code> is used so that the we don't need to burdened ourselves with this. It allows pending micro-tasks to be processed synchronously using flush.<\/code>## Testing Effects<\/p>\n
    The MockStore<\/code> does not trigger reducers or effects. The former are just functions and can be tested in a straight forward way. Replacing action$<\/code> is a good way to test effects. The test setup in the last section has already taken care of that. A test based on this could now use the observable action$<\/code> to send an action to which the tested effect reacts: <\/p>\n
    it('load flights', () => {\n  const effects = TestBed.inject(BookingEffects);\n  let flights: Flight[] = [];\n\n  effects.loadFlights$.subscribe(action => {\n    flights = action.flights; \/\/ Action returned from Effect\n  });\n\n  actions$.next(loadFlights({ from: 'Paris', to: 'London' }));\n    \/\/ Action sent to store to invoke Effect\n\n  const ctrl = TestBed.inject(HttpTestingController);\n  const req = ctrl.expectOne('https:\/\/[\u2026]\/flight?from=Paris&to=London');\n  req.flush([{}, {}, {}]);\n\n  expect(flights.length).toBe(3);\n});<\/code><\/pre>\n
    In the case under consideration, the effect triggers an HTTP call answered by the HttpTestingController<\/code>. The response contains three flights, represented by three empty objects for the sake of simplicity. Finally, the test checks whether the effect provided these flights via the outbound action. ## Summary<\/p>\n
    More and more libraries offer Standalone APIs for mocking dependencies. These either provide a mock implementation or at least overwrite services in the actual implementation to increase testability. The TestingModule<\/code> is still used to provide the test setup. Unlike before, however, it now imports the standalone components, directives, and pipes to be tested. Their classic counterparts, on the other hand, were declared. In addition, the TestingModule<\/code> now includes providers setup by Standalone APIs. ## More on Standalone Components?<\/p>\n
    Learn all about Standalone Components in our free eBook: - The mental model behind Standalone Components<\/p>\n