DEV Community: Chuck Blaine

How We Test Angular2+ (Part 2)

Chuck Blaine — Sat, 11 Sep 2021 21:48:25 +0000

Hey there. This is part two in a series of undefined length. See what I did there?

In part one I gave a little intro and explained that I'm trying to write these blogs with as much detail in each step (including the issues you will inevitably run into) as possible. I'll try to be consistent in format so you can learn the pattern and jump to what interests you easier as time goes on. If you want to play with the code you can find it here.

Previously, we got the sample angular app that comes with the cli up and running and got our tests running. Now we'll add some kind of functionality to our app. I want to get as many bells and whistles going ASAP so we can grow the app uniformly instead of adding libraries and things along the way so we're going to install a bunch of stuff to start off. I'll explain details about each package as it becomes necessary.

The Goal

Add a module
Install and configure an NgRx store
Write some tests and simple functionality

The Setup

First let's get NgRx installed by running the following command.

ng add @ngrx/store@latest

I like using the CLI for stuff like this because other nerds have already done the work of updating module files and doing the npm install for us and I'm lazy so they did it specifically for me and who am I to deny their hard work? You can do all kinds of things by passing optional parameters so check out the docs sometime.

Let's start by running our tests. We'll try some TDD 🙂

The Process

First some housekeeping. Get rid of the sample template stuff.
- Clear out the app.component.html file. When you do you should see your tests start to fail. Go ahead and clear out the tests for now too. You should be seeing TOTAL: 0 SUCCESS now.

Now let's make something!

I thought about this for a while and decided I'm going to build something for myself and I guess anybody else that wants it 🙂. I play D&D and am a lazy programmer with terrible handwriting so I want somewhere I can keep track of the events of campaigns. I want to track things like characters we meet, quests we go on or are available to explore, locations we visit, important notes about those locations, and probably tons of other stuff that I haven't thought of. So let's get to it.

Add a module

The main "object" in D&D is the campaign itself so I'm thinking we add a module for the campaign and then we'll add submodules for all the pieces. I'm going to try and use the cli as much as possible because I don't usually and I want to learn it better.

We'll ask the cli to generate us a module called Campaign (the cli will append "Module" onto the name for us). We can also have it do a few other things for us by passing some switches. We'll tell it that
- the --module App is where the Campaign module will be defined
- we want the --route "campaigns" to map to the new module.
- we want --routing to be setup for the new module as well so we can lazy load sub modules

You can read all about the cli options in the docs

ng g module Campaign --module App --route "campaigns" --routing true

If you've followed along up to this point and start the app then you should see the "campaign works!" string in the browser... right? That's what we want.

Here's what actually happened for me... I see nothing. Then I remembered that we deleted all the template stuff out of the app component so it's empty. Here's what I did next...

Added "App works!" to the app.component.html and then that showed up but the "campaign works!" string still wasn't showing.
Remembered we have to add the <router-outlet></router-outlet> to the app component template. But that still didn't do it...
Looked at the browser and saw that the url was http://localhost:4200/ but I knew that I wanted the /campaigns/ route to map to my Campaign component so then I also knew I had a routing issue.

We have two routing modules right now, one at the App level and one at the Campaign level. Since we're just at the root of our app right now, let's look at the root routing module app-routing.module.ts.

If we inspect the routes that the cli set up for us we can see that we indeed got the mapping we asked for but the issue is that we're not routed to that route by default.

Added an entry to the array telling the router that if the full route (i.e. all the stuff after the localhost part) in the browser is empty then send the request to the campaigns route. The "campaign works!" string started showing up after this last change.

{ path: '', redirectTo: 'campaigns', pathMatch: 'full' }

Add our first feature component

I'm going to add some interfaces and some factory functions for building fake objects in our tests and then I'll make a new component for creating campaigns with the following command. You can check out the details of the files in the repo if you're interested.

generate a ccomponent called NewCampaign under the module Campaign and set the changeDetection policy to OnPush
- Note: the cli will add a prefix to component selectors by default. You can customize this with the --prefix switch and passing a string or you can use the --selector switch to explicitly set the entire selector string. I'm removing the default app- prefix.
  
  ng g c NewCampaign -m Campaign -c OnPush --prefix ""
Let's add the <new-campaign></new-campaign> element to the CampaignComponent template and now we should see our "new campaign works!" string.

TDD time.

We'll try to emulate the fail, refactor, pass pattern for TDD. We'll write a failing test and then refactor code until it passes and then just keep doing that over and over.

When you create a component with the cli Angular will add a test file for you with the standard jasmine syntax. I'm going to use Spectator so this:

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

import { NewCampaignComponent } from './new-campaign.component';

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

  beforeEach(async () => {
    await TestBed.configureTestingModule({
      declarations: [ NewCampaignComponent ]
    })
    .compileComponents();
  });

  beforeEach(() => {
    fixture = TestBed.createComponent(NewCampaignComponent);
    component = fixture.componentInstance;
    fixture.detectChanges();
  });

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

will become this:

import { createComponentFactory, Spectator } from '@ngneat/spectator';
import { NewCampaignComponent } from './new-campaign.component';


describe('NewCampaignComponent', () => {
  let spectator: Spectator<NewCampaignComponent>;
  const createComponent = createComponentFactory({
    component: NewCampaignComponent
  });

  beforeEach(async () => {
    spectator = createComponent();
  });

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

Spectator just takes care of a lot of boilerplate code that gets repeated in practically every test.

You can get some nice syntactic sugar and utilities for your tests by installing Spectator which is made by the fine folks at ngneat. Install it like so. Again, I'll explain things as we go and as we need.

npm i @ngneat/spectator

I have mixed feelings about libraries like this because they can obscure what's going on under the sheets and then when things go wrong it can be even harder to figure out the problem. With that in mind, I still find the convenience that Spectator provides sufficient to accept the risk.

Let's write a test for our NewCampaign component. I want a field for every property on my model so let's start there. Here's my first test:

  it(`should have a firstName field`, () => {
    const firstNameField = spectator.query('input.campaign-name');
    expect(firstNameField).toBeTruthy();
  });

Adding an f to the front of the describe in a spec file focuses the test runner on that test. This will reduce the noise a bit as time goes on. What I see in my console is this:

So we got the first step done. Failing test ✅. Now all we have to do is make it pass. As an aside, one of the reasons I like TDD is that it drives your design process from a consumer perspective. More on that later.

Let's add an input with a class called campaign-name. Adding this to the template turns our test green.

<input type="text" class="campaign-name" [placeholder]="'Enter a Campaign Name'" />

Refactor Code ✅
Passing Test ✅

We'll repeat this process for the other properties of the model by first writing a test that fails and then adding the code to make it pass. Try this with a couple more model properties for funsies. Then let's pause on this and switch gears for a moment.

Wiring up the NgRx store

I mentioned bells and whistles earlier so let's get our store set up and some peripherals we use for our development process.¹ When we ran the ng add command at the very beginning of this post the cli did some housekeeping for us like updating the app.module.ts to import the StoreModule.forRoot(). We need to do a few similar things before we're ready to roll with the NgRx store. I'm not going to cover how Angular module factories and injectors work or how NgRx works but if you have questions just post them below and I'll do my best to help out.

If you use NgRx you should consider using entity state. This is nice for managing state in NgRx. Again, post any questions below.

ng add @ngrx/entity@latest

Just setup enough of the store so that it loads. The minimum is:

Add StoreModule.forRoot({}) to the imports array of the App module
Add StoreModule.forFeature() to the imports array of the Campaign module
- Create a campaign reducer and add it to the forFeature() arguments list

If you have the redux dev tools² setup in your browser you should see the store with your state there now kind of like this:

The Sausage

We got a module created and a new component added inside that module. We also got our NgRx store setup and have an action that we can dispatch from our component and a corresponding reducer function that will allow us to persist data to the store. And we even have some tests. 🙂

The Credits

We've come a long way already! Much of the work we've done up to this point has been foundational stuff but in the next episodes we'll start having more fun by spending more time building helpful features and more testing all along the way. I'll try to dedicate attention to this blog more often so that there aren't such big gaps between posts but life is busy and it doesn't seem to be slowing down.

As always, I welcome questions, discussions, and suggestions for the types of features you'd like to see implemented in the app.

Thanks for spending some of your time with me. Be Well.

I'm showing how we do things at NHA in this project. It's arguable that NgRx is overkill for this project right now but there are other benefits besides scaling. Maybe we can have a post sometime where we could manage local subjects and observables instead of using NgRx store. ↩
Pro Tip: If you're going to work with NgRx do yourself a favor and get the Redux Dev Tools extension for your browser. You won't regret it. Also have a look at the docs because you have to make a change in your module file in order to use the tools. ↩

How We Test Angular2+

Chuck Blaine — Sun, 20 Jun 2021 16:10:02 +0000

Hi, I'm Chuck. This will be my first attempt at trying to contribute back to the community in some way and I'm going to try and do it in the realm of testing. So bear with me 🙂. I appreciate all feedback and constructive feedback is the most helpful.

Throughout my career as a developer I have heard a lot of people agree that testing our code is something that we should all be doing. Conversely, I have not worked at many places that actually do it. Additionally, and surprisingly to me, rarely if ever do you see a tutorial show any kind of testing when they're trying to teach something unless they're specifically teaching testing.

While I understand that the focus of the lesson may not be testing, I think that if we really want to see testing adopted more widely across our industry then we need to normalize it as part of the standard development process and show examples of it happening in practice. I think this will help to remove barriers that may be holding some people back. OK... rant over. Let's get into it and see how the sausage is made.

The Goal

The objective for this first post is to walk through the setup process so we can get to a point where we have a running test. It'll be trivial and useless but let's crawl before we walk.

The Setup

I'm starting from scratch. Nothing at all except an empty repository which you can find here. I'm going to document all of my steps so you can see what I'm going through instead of a super curated end product that says, "Here, just [insert steps that should really not be prefaced with the word "just"] and presto you're testing! GLHF!". SPOILER: The real world doesn't work like that. Instead it's filled with all kinds of WTF moments and banging your head against Google search results. This has been my experience. Your results may vary.

The Process

OK. First things first. Let's get an angular app setup. To do that we leverage the Angular CLI and run a command that looks something like:

ng new angular-testing-demo

And the very first thing I see is an error saying 'ng' is not a recognized command. That's because I don't have the cli installed in my global npm environment. So it's not a lie. We fix that with this command:

npm i -g @angular/cli

Now when we run the ng new command it'll be recognized. Cool, one StackOverflow search eliminated. You're welcome.

Let's try and run the tests

npm run test

Neat. Tests are running. Pretty quick and easy actually.

I say that because I've never actually setup tests from scratch before this. Again, the real world rarely looks like what you see online (crazy right?).

The Sausage

We're set up from scratch in very little time and have running tests. That's all I wanted to accomplish for the first post so we'll stop here. In the following posts we'll start adding more and more complexity to the app and I'll try to incorporate all the fancy bells and whistles that we're using in our code because that's the type of complexity you'll encounter in the real world.

Bonus Scene Right Before The Credits

The browser UI is nice to look at but we really don't need it right now so let's turn it off. By default, the CLI will set you up using Karma as a test runner and Jasmine as your testing framework. There is a file that gets generated called karma.conf.js where you can tweak how tests will run and near the end of that file you'll see a key for browsers.

// browsers: ['Chrome'], // This is what you'll see there already
browsers: ['ChromeHeadless'], // This is what you want it to be

Now when we run our tests Karma won't try to open an actual browser but will instead use a Headless browser which runs in memory.

One more StackOverflow search eliminated.

The Credits

When we started our testing initiative at NHA, we already had a pretty good sized application running with many modules and submodules, custom SCSS, custom Javascript extension functions, NgRx state management, the list goes on. So when we went to get things setup it was not at all as easy as what I just showed you.

So I'm curious to know if anybody else is stuck in a similar spot and has an existing codebase in place where they're trying to get started testing and the tutorials don't explain enough to help.

I welcome questions, discussions, and suggestions for the types of features you'd like to see implemented in the app.

Thanks for spending some of your time with me. Be Well.