If that’s the case, then you’re probably relying on services to manage state as it’s the out-of-the-box method presented to us by the Angular team.

The gist of services is to abstract away any business logic from our components, and subscribing to any state that we need to use within the component.

One common task that we routinely find ourselves doing when relying solely on services for state management is creating semaphore variables to determine whether or not a certain piece of state is loading and as a result displaying some kind of message or icon to the user letting them know that it may be a moment before the data is ready. Error handling also mimics this same pattern where we’re using Subjects or BehaviorSubjects and subscribing to them over and over again. Based on the truthiness of a variable like “hasErrors”, we can display a message letting the user know something unexpected happened and it requires their attention.

The async pipe provided to us by Angular out of the box is a great way to get around having to set up numerous subscriptions within our component TS files, and comes in especially handy when you’re working on a small to mid-sized application that doesn’t have extremely complex state and control flow.

Let’s take a look at the traditional way of setting up a simple service and a method to fetch some data from an external API, and then subscribe to that data from within a component:

import { Injectable } from '@angular/core';
import { BehaviorSubject, of } from 'rxjs';
@Injectable({
  providedIn: 'root',
})
export class CounterService {
  count$: BehaviorSubject<number> = new BehaviorSubject<number>(0);
  isLoading$: BehaviorSubject<boolean> = new BehaviorSubject<boolean>(false);
  constructor() {}
  increase() {
    this.isLoading$.next(true);
    setTimeout(() => {
      this.count$.next(this.count.value + 1);
      this.isLoading$.next(false);
    }, 3500);
  }
}

The above service is somewhat contrived, but it’s a good example to show us how subscribing to the isLoading variable can be abstracted away using the async pipe within our component template files. Let’s take a look at how how we’d implement showing the user some kind of loading prompt within the use of the async pipe:

import { CounterService } from '../services/counter.service';
import { Component, OnInit } from '@angular/core';
@Component({
  selector: 'app-my-counter',
  templateUrl: './my-counter.component.html',
  styleUrls: ['./my-counter.component.scss'],
})
export class MyCounterComponent implements OnInit {
  count: number;
  isLoading: boolean;
  constructor(public countService: CountService) {}
  ngOnInit(): void {
      this.countService.count$.subscribe((count) => {
        this.count = count;
      })
      this.countService.isLoading$.subscribe((isLoading) => {
        this.isLoading = isLoading;
      })
    this.countService.increase();
  }
}

Lines 21 – 23 are where things start to get really repetitive and you’ll find yourself setting up at least 3 subscriptions per component, assuming that each component always has some kind of meaningful external state (In our example the count variable), and semaphore variables for both loading and errors.

Also note: Line 14 we’re also marking the counterService public instead of private like we typically do when we handle dependency injection via the constructor’s parameters. If we did not do this, the counterService would not be available within the associated template file that we’re going to work with next.

Let’s abstract that away from our component TS files and implement it within our template files instead using the async pipe:

<div *ngIf="counterService.isLoading$ | async; else showCount">
    Loading... Please wait!
</div>
<ng-template #showCount>
    {{ counterService.count$ | async }}
</ng-template>

What a difference! We no longer have to set up subscriptions within our component TS files but can instead lean on the async pipe to manage the subscriptions and assignments for us!

The async pipe is great because it subscribes to the observable stream and takes whatever values comes across the stream and interpolates it within the template without us having to specifically initialize a local template variable and handle the assignment based on the subscription.

Just to be clear, this will work when working with not-so-complex states generally found in smaller to mid-sized apps. This pattern starts to break down once you start introducing things like role based authentication, really in depth control flow, or a more complex object with nested objects and other data structures and collections.

If you’re a less experienced front end developer and are looking to up your JavaScript game, forcing yourself to create a few Angular apps is a great way to really level up your JS skill set. React and Vue do a great job at abstracting things away so some things that happen just seem like magic. Angular still has abstractions however not to the extent of the other two so you’re forced to roll up your sleeves and up your JS game. (This is really just me saying the learning curve for Angular is more demanding that any other front end framework.)

Angular ships with RxJS and it’s a complete paradigm shift in that you no longer simply rely on fetch() or axios.get() to handle your HTTP requests in your app. RxJS instead allows us as developers to subscribe to a data stream and listen to it for any changes while the subscription is active. To be fair, you can implement RxJS in either a React or Vue app, but neither ships with it out of the box so it’s up to you the install it as a dependency and use it (Convention over configuration… Remember?)

Subjects and BehaviorSubjects are observables that can emit their values to multiple observers via subscriptions. On the surface we’re almost inclined to think that both a Subject and a BehaviorSubject do the same thing, but the differences are subtle and can make a pretty big impact on your application.

In simple terms: A Subject does not need to have an initial value when being created but a BehaviorSubject requires an initial value when being created. Therefore, a Subject will only emit upcoming values, whereas a BehaviorSubject will emit one previous value and all upcoming values.

Let’s set the stage for a pretty common example front end developers handle on a routine basis: showing or hiding a modal to let the user edit settings. As you can imagine, this is a good use case for a BehaviorSubject because we’ll want to set the initial value of “showModal” to “false”.

// src/app/services/modal.service.ts

import { BehaviorSubject } from 'rxjs';

export class ModalService {
  showModal = new BehaviorSubject<boolean>(false);

  toggleModal() {
    this.showModal.next(!this.showModal.value);
  }
}

Had we not passed in a boolean value to the BehaviorSubject’s constructor, TypeScript would have immediately given us an error indicating that one argument was expected, but we’ve given it 0.

The above example sets up an Angular service that we can then import into any other component and utilize the toggleModal() method. Any subscriptions to this observable therefore will receive an initial value of “false” since BehaviorSubjects allow us to track and initial value and any subsequent changes in the future.

On the other hand, a Subject does not require an initial value. In sticking with the modal example from above, a good parallel use case for a Subject would be if upon the user opening a modal in the app we want to display a form containing the app’s settings that they can modify and then save. Let’s take a look:

// src/app/services/settings.service.ts

import { Subject } from 'rxjs';
import { HttpClient } from '@angular/common/http';

export class SettingsService {

  appSettings = new Subject<Settings>();

  constructor(private http: HttpClient) {}

  getAppSettings() {
  this.http.get<Settings>('https://www.myapp_api.com/settings')
    .subscribe((settings: Settings) => {
      console.log(settings, 'Settings received from API call.');
      this.settings.next(settings);
    )};
  }

}

Sure, there’s a little more code than the previous BehaviorSubject example but most of it is simply boiler plate code in order to set things up. The key takeaway here should be that when we create a new Subject, we do not have to supply its constructor method with an argument to set the initial value upon creation. We only have to indicate what kind of value will be occupying it in the future, which in this case is an object of type “Settings”.

We’ve defined a getAppSettings() method that we can again import into any other component and fetch our user’s app settings from the back end and then once the request comes back we will push the new value via the next() method and any subscriptions made will finally receive their first value. We will then have access to the app settings, now stored with the label appSettings, be it an object of settings or an array.

So what’s the tl;dr version of all of this? Pretty simple, actually:

Use a BehaviorSubject if you need an initial value (The modal example above is a really good example) and use a Subject if you do not need an initial value.

A unit test is a smaller piece of the TDD paradigm in which it sets out to test a single unit of code – in most cases a function or method – to ensure that when it runs in a controlled environment the code behaves as we intended it to do so.

When we say unit testing as it relates to Angular, in most cases we’re talking about testing a single component to ensure that its functionality works as intended and no breaking changes have been introduced. (We can also unit test services, directives, and pipes) By default, Angular comes out of the box with Jasmine and Karma to assist with unit testing. Jasmine is a testing framework that gives us things such as spies and pattern matching, whereas Karma is a task runner that helps us with the execution of the tests.

When we generate a new component using the Angular CLI (ng generate component users) in addition to it generating our usual CSS, HTML template, and TS Class file, it also generates a .spec.ts file for us that scaffolds a basic test for us that ensures the component is at least successfully created. Certainly a great starting point!

Let’s take a look at what the CLI gives us after running the above ng generate command:

import { ComponentFixture, TestBed } from '@angular/core/testing';

import { UsersComponent } from './users.component';

describe('UsersComponent', () => {
  let component: UsersComponent;
  let fixture: ComponentFixture<UsersComponent>;

  //SECTION 1
  beforeEach(async () => {
    await TestBed.configureTestingModule({
      declarations: [ UsersComponent ]
    })
    .compileComponents();
  });

  //SECTION 2
  beforeEach(() => {
    fixture = TestBed.createComponent(UsersComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

  //SECTION 3
  it('should create', () => {
    expect(component).toBeTruthy();
  });
});

I’ve added several comments to act as section headers to better assist in explaining what’s going on.

Section 1
This beforeEach block runs before each test we define later on in the spec file. We’re setting up a Test Bed, which is a controlled Angular environment for our tests to run in. Notice how the configureTestingModule method takes in an object as its argument and within that object we have a declarations property that is an array. Where else have we seen this? When ever we declare a module using the @NgModule decorator, of course! We’re essentially setting up a mini-module to test our component in!

Section 2
This second beforeEach block is where we’ll actually be setting up an instance of the component we want to test.

TestBed.createComponent(UsersComponent) returns to us a TestBed with an instance of the UsersComponent, and on the very next line we’re setting our component variable to fixture.componentInstance property which is an instance of our component that we can now run tests on!

fixture.detectChanges() gives us access to any changes to the component – it’s essentially refreshing the component after we’ve run a method or made some changes to some of the component’s properites.

Section 3
Finally! What we’ve been waiting for! Section 3 is where we’re actually writing our tests – Remember before each of these tests run, sections 1 and 2 will run each time – hence the beforeEach blocks. This boiler plate test lets us know that the component is created successfully without any bugs that are preventing it from compiling/loading.

Putting it all together

Let’s take things a step further. Let’s create a test for a login form that should only attempt to authenticate a user if the username and password fields are filled out. This is a great example because not only is it a real world use case, but it’ll also show us how to incorporate spies into our unit tests. Our login form also relies on a service, in this case the authService, so it’ll also give us a chance to look at how we incorporate services into our tests as well.

import { ComponentFixture, TestBed } from '@angular/core/testing';
import { FormsModule, NgForm } from '@angular/forms';
import { AppRoutingModule } from 'src/app/app-routing.module';
import { AuthService } from 'src/app/services/auth.service';

import { LoginComponent } from './login.component';

const authServiceStub = {
  login: () => {},
  signup: () => {},
  user: {
    subscribe: () => {},
  },
};

describe('LoginComponent', () => {
  let component: LoginComponent;
  let authService: AuthService;
  let fixture: ComponentFixture<LoginComponent>;

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      declarations: [LoginComponent],
      imports: [AppRoutingModule, FormsModule],
      providers: [{ provide: AuthService, useValue: authServiceStub }],
    }).compileComponents();
  });

  beforeEach(() => {
    fixture = TestBed.createComponent(LoginComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
    authService = TestBed.inject(AuthService);
  });

  it('Should not attempt to authenticate user if the form is invalid', () => {
    const authSpy = spyOn(authService, 'login');
    const testFormData = <NgForm>{
      valid: false,
      value: {
        email: '',
        password: '',
      },
    };
    component.onSubmit(testFormData);
    fixture.detectChanges();
    expect(authSpy).toHaveBeenCalledTimes(0);
  });
});

A few important things to take note of that differ from the boiler plate code the Angular CLI gives us:

• We create an object called authServiceStub that stubs out all of the methods/properties that our login component will interact with. In the majority of cases it’s alright to just create no-op functions. We can run them, but we don’t expect anything to happen. We can spy on them to see if they do or do not run, and how many times if they do run.
• The login component relies on the AppRoutingModule as well as the FormsModule. These must be imported into our test module via the imports array.
• We need to provide the AuthService to this module, but we don’t want to test the logic within the service itself when unit testing this component. At this point we don’t really care how the service’s login and signup methods work. We just want to ensure that our login component actually runs them when expected. We’ll more or less overwrite most of its functionality via the useValue property.
• We inject the new mock AuthService into the TestBed so we can later interact with it and spy on its methods.

Lastly, let’s take a look at the single it spec from above:

  it('Should not attempt to authenticate user if the form is invalid', () => {
    const authSpy = spyOn(authService, 'login');
    const testFormData = <NgForm>{
      valid: false,
      value: {
        email: '',
        password: '',
      },
    };
    component.onSubmit(testFormData);
    fixture.detectChanges();
    expect(authSpy).toHaveBeenCalledTimes(0);
  });

We’re doing a few important things here:

• We’re creating a spy. We’re going to spy on the login method from our newly created authService that we injected into this test bed.
• We’re setting up basic form data that we know should result in the login function not running.
• We attempt to run the component’s onSubmit function with the testFormData as an argument and we’re refreshing to get any changes.
• Finally, we’re checking to see how many times the login function was run thanks to the authSpy. We’re expecting this value to be 0. If it’s been run 1 or more times the test will fail and we know that we introduced breaking changes into our code. (Did we remove a conditional, perhaps?)

What about DOM elements?

The above example didn’t verify that an error message was being presented to the user, which would be somewhat of an awkward user experience if we just left them guessing as to why nothing is happening while using the application. How would we go about creating a unit test that also ensures that some kind of error message is being shown to the user? Let’s take a look at another it block:

  it('Should display a div that contains an error message in the event of a user error during login', () => {
    const testFormData = <NgForm>{
      valid: false,
      value: {
        email: '',
        password: '',
      },
      reset: () => {},
    };
    component.onSubmit(testFormData);
    fixture.detectChanges();
    const loginElement: HTMLElement = fixture.nativeElement;
    expect(loginElement.querySelector('#error-container')?.innerHTML).toContain(
      'Must provide valid credentials'
    );
  });

A lot of this is pretty similar to the previous example. The main difference is that after we attempt to submit the form with data that we know will cause it to fail, we run fixture.detectChanges() to “refresh” the component, and then we access the underlying HTML element via fixture.nativeElement. We then create an expect/toContain check that accesses the HTML element that has error-container as its ID and ensures that its innerHTML contains the string “Must provide valid credentials”.

Wrapping things up

Overall, unit testing can be challenging, but as an application grows and development teams have to move faster, it speeds up the overall development process and decreases errors going into production because you can immediately check to see if the changes you are making have unintended consequences elsewhere in the application. It’s also important to note that as a best practice, it’s best to write the majority of tests before writing any code in order to ensure you’re not introducing biases – It is test driven development, afterall!