{"id":24334,"date":"2024-01-25T08:07:29","date_gmt":"2024-01-25T07:07:29","guid":{"rendered":"https:\/\/www.angulararchitects.io\/blog\/testing-angulars-latest-features\/"},"modified":"2024-01-26T18:29:59","modified_gmt":"2024-01-26T17:29:59","slug":"testing-angulars-latest-features","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/testing-angulars-latest-features\/","title":{"rendered":"Testing Angular’s Latest Features"},"content":{"rendered":"

1. Standalone & Mocking<\/h2>\n

If you prefer the kind of tests where you minimize your mock as much as possible, you will be quite happy with Standalone Components. Forgotten are the days when we had to carefully select only those dependencies from an NgModule<\/code> that belong to the component under test and move it over to the TestingModule<\/code>.<\/p>\n

The Standalone Component has everything in it. Just add it to the imports<\/code> property of the TestingModule<\/code>. All its "visual elements", like sub components, directives, and pipes, and their dependencies are now part of the test as well. In terms of code coverage, that's quite huge.<\/p>\n

When we write a test, we check what services our component requires. Typical candidates are HttpClient<\/code>, ActivatedRoute<\/code>. We need to mock them. That's doable.<\/p>\n

Unfortunately, the components' dependencies also require services, which - some of them - we also have to provide.<\/p>\n

Let's look at the following component RequestInfo<\/code>, we want to test:<\/p>\n

<\/p>\n

A huge amount of services derive from RequestInfoHolidayCard. With NgRx, we have quite an additional heavy dependency.<\/p>\n

Looking at the necessary setup of the TestingModule<\/code>, there is quite a lot to consider:<\/p>\n

const fixture = TestBed.configureTestingModule({\n  imports: [RequestInfoComponent],\n  providers: [\n    provideNoopAnimations(),\n    {\n      provide: HttpClient,\n      useValue: {\n        get: (url: string) => {\n          if (url === "\/holiday") {\n            return of([createHoliday()]);\n          }\n          return of([true]).pipe(delay(125));\n        },\n      },\n    },\n    {\n      provide: ActivatedRoute,\n      useValue: {\n        paramMap: of({ get: () => 1 }),\n      },\n    },\n    provideStore({}),\n    provideState(holidaysFeature),\n    provideEffects([HolidaysEffects]),\n    {\n      provide: Configuration,\n      useValue: { baseUrl: "https:\/\/somewhere.com" },\n    },\n  ],\n}).createComponent(RequestInfoComponent);<\/code><\/pre>\n
What we want to achieve is that we mock only the RequestInfoHolidayCard<\/code>. That would free us from quite a lot of service dependencies:<\/p>\n
<\/p>\n
To mock a component, we do it the manual way. There are third-party libraries available, like ng-mocks, which provide functions to automate that.<\/p>\n
We add the code of the mocked Component directly into the test file<\/p>\n
@Component({\n  selector: "app-request-info-holiday-card",\n  template: ``,\n  standalone: true,\n})\nclass MockedRequestInfoHolidayCard {}<\/code><\/pre>\n
The MockedRequestInfoHolidayCard<\/code> is a simple component without any dependencies. What it has in common with the original is the selector. So when Angular sees the tag <app-request-info-holiday-card><\/code>, it would use the mocked version.<\/p>\n
The next step is to import the mock into the TestingModule<\/code>. With all its dependencies gone, the TestingModule<\/code> setup slims down quite a bit:<\/p>\n
const fixture = TestBed.configureTestingModule({\n  imports: [RequestInfoComponent, MockedRequestInfoHolidayCard],\n  providers: [\n    provideNoopAnimations(),\n    {\n      provide: HttpClient,\n      useValue: {\n        get: (url: string) => of([true]).pipe(delay(125)),\n      },\n    },\n  ],\n}).createComponent(RequestInfoComponent);<\/code><\/pre>\n
Unfortunately, that does not work. The test fails because ActivatedRoute<\/code> (dependency of RequestInfoHolidayCard<\/code>) is not available.<\/p>\n
The reason should be clear. RequestInfoHolidayCard<\/code> is not part of the imports property of some NgModule but directly of the RequestInfoComponent<\/code>. Although the mocked version is now part of the TestingModule<\/code>, the imports coming from RequestInfoComponent<\/code> internally override it.<\/p>\n
Our only chance is to access the imports property of the component itself. Luckily, there is a TestBed.overrideComponent<\/code>. A method, made for that use case. After replacing the original with the mock, we configure the TestingModule<\/code> and proceed with the actual test.<\/p>\n
TestBed.overrideComponent(RequestInfoComponent, {\n  remove: { imports: [RequestInfoComponentHolidayCard] },\n  add: { imports: [MockedRequestInfoHolidayCard] },\n});\n\nconst fixture = TestBed.configureTestingModule({\n  imports: [RequestInfoComponent],\n  providers: [\n    provideNoopAnimations(),\n    {\n      provide: HttpClient,\n      useValue: {\n        get: (url: string) => of([true]).pipe(delay(125)),\n      },\n    },\n  ],\n}).createComponent(RequestInfoComponent);<\/code><\/pre>\n
Et voila, that's much better!<\/p>\n
A set<\/code> method would override the complete imports<\/code>, providers<\/code>, etc. properties.<\/p>\n
Please note that I highly recommend that you use ng-mocks. It is way more comfortable to mock Components, Pipes, and Directives with it.<\/p>\n
2. inject()<\/code><\/h2>\n
With the introduction of the inject<\/code> function in Angular 14, it became quite clear that we ought to use it over the constructor. To give you some reasons:<\/p>\n