DEV Community: Marcin Milewicz

Why Your Angular Tests Probably Smell

Marcin Milewicz — Sat, 08 Jul 2023 09:34:07 +0000

Why Your Angular Tests Probably Smell

Common pitfalls encountered when testing Angular projects

Testing an Angular application is inherently straightforward. Angular frameworks are built from the ground up so their abstractions are easy to test. Default loose architecture, splitting logic into components, directives, services, modules or pipes — all of these significantly help us in the testing process itself. If we follow proven patterns and produce truly testable code, testing shouldn’t be a nuisance — it should be something that facilitates reliable code development.

You’ll never walk alone

Moreover, Angular does not leave us alone on the battlefield — it equips us with a powerful set of tools that facilitate and accelerate writing tests.

As Angular users, it’s our responsibility to learn these tools thoroughly. In this Angular Testing Series of articles, I would like to present the typical and correct use of built-in unit testing mechanism in Angular, based on prepared examples.

Bad testing habits

Bad habits often come from temptation. I’ve noticed that we (developers) also often give in to one temptation: copying a code for unit testing. This technique has two faces:

We can stick to a consistent way in testing and accelerate our productivity and bringing value.

Or, if we do not know what we’re actually copying:

We can contribute to smearing smelly pieces of code among all the tests in the projects.

In this article, I would like to focus on those smelly pieces of code in unit tests that I have encountered in various Angular projects.

Component Testing

Let’s assume this is our component under test:

We would like to verify whether Full Names is rendered into the tag. Let’s look at the following test:

When we run jest everything works:

But something smells — can you tell what it is?

Let’s take a look at the last test and see what’s going on there. ngOnInit is called, change detection is simulated in fixture, and assertion is made when the fixture template is ready. Apparently, everything is OK, but this is a distortion of the truth and a bad simulation of the component’s life cycle. In this example, everything will work out as expected. However, the method ngOnInit is called twice. The change detection is also performed one more time.

How should we handle it?

What should we do to make our test reflect reality is to get rid of the ngOnInit call? Instantiated fixture:ComponentFixture has appropriate responsibility and when we call on it detectChanges method, we can trust that the individual component lifecycle methods will be executed automatically.

In the above gist, I changed one more thing. The async function was replaced with waitForAsync. Why? Because in Angular 10, the async function is finally marked as deprecated and we can expect that in Angular 12 we won’t see it at all.

Don’t care about rendering in tests

Quite often we find and write component tests where it is not important to check if actual values are generated in the DOM. Whether this is a good or bad approach depends only on your test findings and objectives, but I would like to mention another common mistake related to this type of test.

Now, we want to verify only if the field title has the expected value assigned. It seems that everything is fine, and the test itself is deterministic, but something stinks about the solution presented.

As mentioned previously, the fixture reflects the template with the generated DOM model. In the above test, we don’t check anything in DOM. Is it worth using resources to create fixture, indeed? This is a typical example of an isolation test. If all tests gathered in the spec collection are isolated, then the entire spec should be implemented, like this:

In isolated tests, we have to remember to call appropriate lifecycle methods like ngOnInit
Isolated tests are significantly faster than shallow tests with ComponentFixture. Even for such simple tests, the difference in resource usage and total test time is significant.

Asynchronous Services and Events

In Angular’s project development, we deal with asynchronous operations most of the time. XHR requests, handling of render/browser events, debouncing of inputs entered by users are all asynchronous tasks, so tests should handle them appropriately.

Let’s analyze the sample scenario with a straightforward service which fetches data as XHRs:

The above service is used by the smart domain component FullNameListComponent.

We would like to test fullNames$ stream. This time, we use ComponentFixture, due to the fact that it’s a convenient way of providing stubs to Angular DI.

Two basic tests can look like this:

The tests are passed. Is it OK? Obviously, not! To find out why I slightly modify the second test:

it('should fullNames be triggered on name change', () => {
  const expectedFullNames = *FAKE_NAMES*;

  component.fullNames$.subscribe((fullNames) => {
    expect(fullNames).toEqual(**null**);
  });

  component.name = 'John';
});

I modified assertation to expect fullNames as null, which is incorrect. The test is still passing. What’s wrong?

fakeAsync for help

Aside from the fact that so-called subscribe-assert is not the best method we can use for stream testing, we often forget about one thing. If the stream runs asynchronously, the test should take this fact into account. Fortunately, Angular provides us with useful tooling: a special fakeAsync zone.

it('should fullNames be triggered on name change', fakeAsync(() => {
  const expectedFullNames = ***FAKE_NAMES***;

  component.fullNames$.subscribe((fullNames) => {
    expect(fullNames).toEqual(null);
  });

  component.name = 'John';
  tick();
}));

Now, the test runner is able to identify that assertion is not correct:

I don’t want to explain exactly whatfakeAsync is here, because that’s not the purpose of this article. However, we must always remember that if we deal with asynchrony, then we should also take it into account in tests.

There is another smelly thing in the above test method. Let’s look at our stub:

Here we simulate returning Observable with fake data. It’s a popular approach, but is it correct? Not at all.

I refer here to a very good article from Netanel Basal. He explains well why of is not an appropriate function to use to fake an API response.

In short, of function provides synchronous data, while the response to an XHR is asynchronous and treated as a macrotask. Faking asynchronous data with synchronous invocation is cheating and stinks. It increases code coverage, but the quality of such tests is questionable.

As providing an appropriate scheduler to the of function is deprecated, I recommend the following approach:

import { ***asyncScheduler***, Observable, scheduled } from 'rxjs';

getFullNames(name: string): Observable<FullName[]> {
  return scheduled([***FAKE_NAMES***], ***asyncScheduler***);
}

Summary

How to avoid such mishaps in tests:

Try to follow Red/Green/Refactor technique. If you don’t use TDD methodology, try to fail your tests on purpose.
See and learn about two features that Angular gives us: waitForAsync and fakeAsync. Be aware of the differences between them.
Don’t use of for faking data. In most cases, you don’t notice any differences. However, there is a framework hacking. Trust the provided fakeAsync zone to simulate synchronous execution.
All examples are gathered in the repository on my Github.

I would be grateful also if you tell me what your consternation with Angular testing is. I will be happy to prepare a pragmatic solution and assist you.

How does APP_INITIALIZER work? So what do you need to know about dynamic configuration in Angular?

Marcin Milewicz — Fri, 07 Jul 2023 08:26:29 +0000

How does APP_INITIALIZER work? So what do you need to know about dynamic configuration in Angular?

When we develop an application designed to run on multiple environments, we have to decide how to provide a configuration of appropriate variables depending on those environments

TLDR; 📕

environment.ts is not the best way to provide an environment configuration
do not introduce environmental configuration in build-time
Special injection token called APP_INITIALIZER is used for convenient and effective external configuration providing
I’ve prepared for you the minimal example which solves this problem by using APP_INITIALIZER. You can find it on StackBlitz

First round ❓

The simplest example of an environmental variable is API configuration. Commonly, we use a different URL depending on target environment. For instance:

In many Angular projects that I have seen, this problem has been solved by using analogous files provided by the Angular framework: environment.dev.ts, environment.test.ts and environment.prod.ts.

These files for our example would look like this

It cannot be said that this approach is very bad or does nor meet the assumptions made. However, look what happens if you choose this way to keep your variables and want to complete the full cycle of application delivery to production.

If everything works fine locally, the application is built on the development environment using the environment.dev.ts file
If everything works fine in the development environment, we can promote it to the test environment. In order for the application to run in the test environment, the application must be rebuilt using the environment.test.ts file this time
If the application has been tested in the test environment and is ready for production, we have to take the same steps. So we need to rebuild the application again using environment.prod.ts

Please note one fact. The application must be built three times (!!!) before it goes from the developer’s hand to the production environment.

The first conclusions that arise are: 👈

If you want to deliver a small change to production, you have to repeat the same building process several times, which will significantly extend the delivery time.
You can never be sure that a tested artifact from the dev environment or test will build correctly on the prod environment

Based on these conclusions and my own experience, I can safely and honestly tell you that environment.ts files are not a good place to hold most types of configuration. More precisely:

Certain configuration types should not be shipped when building an artifact. Storing environment-dependent variables in Angular’s environment.ts is the anti-pattern. Unfortunately, common anti-pattern.

So if you choose not to hold your configuration in environment.ts, what can you do?

Round 2 — APP_INITIALIZER approach 💪

Angular’s Injection Token APP_INITIALIZER comes with great help, thanks to which you can introduce additional initialization functions to your application. This functionality of the Angular framework ensures that the provided functions are executed when an application is started, while an application is still being initialized. These functions return a Promise object and an Angular’s app will not be initialized until it is being executed.

Is is a proper way to pass the configuration?

Of course! Even in the official Angular framework documentation, you can read: 📕

You can, for example, create a factory function that loads language data or an external configuration, and provide that function to the APP_INITIALIZER token. That way, the function is executed during the application bootstrap process, and the needed data is available on startup.
Follow me on Twitter if you want to be updated about new great Angular and frontend stuff! 😄

Runtime configuration in practice

Firstly, we need a file to hold configuration details in, and it will not be part of JavaScript artifacts which are built when ng build is executed. This configuration file should be downloaded on demand when the application is initialized.

for the following assumed configuration model.

We also need a service that has the responsibility to download the configuration and make it available while the application is running.

The last step is to use the above method with the APP_INITIALIZER token. It is used in the providers section for a specific NgModule.

It’s worth to consider creating a separate module dedicated to fetching configuration instead of adding the following code to the main app.module.ts

The loadConfiguration function is provided with the useFactory parameter. The function itself looks like this

By following the steps above, we ensure the following behavior for our application

when the application is started, the loadConfiguration from the ConfigurationLoader instance is run and it starts downloading the configuration from /assets/config/configuration.json
the application waits until the configuration is loaded from /assets/config/configuration.json
Finally, the application is initialized and the configuration is available through getConfiguration method of ConfigurationLoader instance

The magic is that the configuration placed in the assets directory is not taken into account at the time of building. You can modify the contents of the assets directory at any time without rebuilding the app. So the scheme for delivering the application to production now looks like this

If everything works fine locally, the application is built on the development environment and the /assets/config/configuration.json file is delivered externally
If everything works fine in the development environment, the application is promoted to the test environment. In order to run the application in the test environment, we take the artifact already built and replace the /assets/config/configuration.json file, which this time contains the configuration specific to the test environment
If the application is passed the tests in the test environment and is ready to go to the production, we take the same artifact again, push it to the prod environment and replace the analogous configuration file /assets/config/configuration.json for the prod environment.

Wow! By using APP_INITIALIZER and runtime configuration approach, you are able to limit the process of building the application in the entire delivery cycle to only one time! Frankly speaking, this one time is the maximum number of times according to the best practices. You also ensured that your built artifact on the initial environment is equal to a single byte with what is placed in the final environment.

If you want to see how this solution works, I have prepared a live example on ***StackBlitz*** for you.

Summary 📕

environment.ts is not the best way to provide an environment configuration in Angular ecosystem. We can safely name it as anti-pattern.
do not introduce an environment configuration which is runtime-dependant
Injection Token — APP_INITIALIZER is used for convenient and effective external configuration delivery in Angular ecosystem.
I have prepared for you a minimal example of solving the problem by using APP_INITIALIZER. You will find him on ***StackBlitz***

The feedback is important and best way in medium.com is clicking multiple times on clap icon 👏 on your left . If you click on it, I will know that my articiles has value for you ❤️ and I will be encouraged to write more 📙. Thanks!

Follow me on Twitter if you want to be updated about new great Angular and frontend stuff! 😄