DEV Community: Jordan Powell

Testing NgRx Store with Cypress Component Testing

Jordan Powell — Fri, 05 Jan 2024 22:07:02 +0000

What is NgRx

NgRx has been one of my most favorite open-source projects I've worked on in my career. It provides several mechanisms for managing reactivity in Angular applications. Most commonly in it's @ngrx/store package in combination with @ngrx/effects. To understand what it does at a high level I like to refer to the diagram below which I created several years back.

This article will not go into the weeds of NgRx but will focus on integrating it with Cypress Component Testing. However, there are endless resources online for learning how to get started with NgRx. I recommend visiting their Getting Started Docs if you want to learn more or are looking for a quick refresher.

Cypress Component Testing

For those of you not familiar with Cypress Component Testing, it provides a component workbench for you to quickly build and test components from multiple front-end UI libraries — no matter how simple or complex.

"I like to say it's like Jest or Karma had a baby with Storybook!"

What I love about it personally is how simple it is to create really meaningful tests! If you are new to Component Testing I recommend watching my video below showing how to get starting with Component Testing in Angular or you can visit the Angular Component Testing Cypress Docs.

Creating Our Store

Let's use a simple example of a counter that both increments and decrements a count and then displays the total count as a number in a StepperComponent. To get started we always want to start with our actions!

// src/app/store/count.actions.ts

import { createAction } from '@ngrx/store' 

export const incrementCount = createAction('[COUNT] increment count')
export const decrementCount = createAction('[COUNT] decrement count')
export const clearCount = createAction('[COUNT] clear count')

Now let's create a reducer to handle our actions:

// src/app/store/count.reducer.ts

import { createFeature, createReducer, on } from '@ngrx/store' 
import { incrementCount, decrementCount, clearCount } from './count.actions'

interface State {
  count: number
}

const initialState: State = {
  count: 0,
}

const countFeature = createFeature({
  name: 'count',
  reducer: createReducer(
    initialState,
    on(incrementCount, ({ count }) => ({
      count: count + 1
    })),
    on(decrementCount, ({ count }) => ({
      count: count - 1
    })),
    on(clearCount, () => ({
      count: 0
    }))
  )
})

export const { name: reducer, selectCountState, selectCount } = countFeature

Now let's create a StepperComponent that will allow users to increment, decrement and clear the count by integrating it with our store.

// src/app/stepper/stepper.component.ts

import { Component, inject } from '@angular/core' 
import { Store } from '@ngrx/store' 
import { selectCount } from '../store/count.reducer' 
import { incrementCount, decrementCount, clearCount } from '../store/count.actions

@Component({
  selector: 'app-stepper',
  template: `
    <button (click)="decrement()">-</button>
    <span>{{ count$ | async }}</span>
    <button (click)="increment()">+</button>
    <br /><br />
    <button (click)="clear()">Clear</button>
  `,
  styleUrls: ['./stepper.component.css'],
})
export class StepperComponent {
  private readonly store = inject(Store)

  count$ = this.store.select(selectCount)

  increment() {
    this.store.dispatch(incrementCount())
  }

  decrement() {
    this.store.dispatch(decrementCount())
  }

  clear() {
    this.store.dispatch(clearCount())
  }
}

Now let's import our StoreModule into our App.Module:

// src/app/app.module.ts

import { StoreModule } from '@ngrx/store' 
import { reducer } from './store/count.reducer'
...

@NgModule({ 
  ...
  imports: [
    ...,
    StoreModule.forRoot({
      count: reducer
    })
  ],
})
export class AppModule {}

Note
You can apply the same concepts for Standalone Components as well https://ngrx.io/guide/store/reducers#standalone-api-in-module-based-apps

Writing our First Test

Now that we have our Store connected to our new Stepper Component, lets install cypress (if you haven't already done so) by running the following bash command:

npm install cypress@latest

Now let's write our first test by creating a new file next to our StepperComponent named stepper.component.cy.ts

// src/app/stepper/stepper.component.cy.ts

import { StepperComponent } from './stepper.component'

describe('StepperComponent', () => {
  it('can mount', () => {
    cy.mount(StepperComponent)
  })
})

Now let's launch Cypress and click on our new spec file:

npx cypress open --component

Though our test was super easy to write we unfortunately get the following error:

This is because we haven't configured our test with our Store. Don't worry this is actually super easy to do! Because we configured our AppModule with our store we can either do one of two things:

We can copy the Store configuration from our AppModule into our mount
We can just import AppModule into our mount

Let's do the later as it requires less code:

// src/app/stepper/stepper.component.cy.ts

import { StepperComponent } from './stepper.component'
import { AppModule } from '../app.module'

describe('StepperComponent', () => {
  it('can mount', () => {
    cy.mount(StepperComponent, {
      imports: [AppModule]
    })
  })
})

And just like that our StepperComponent connected to our store is mounting successfully in our Cypress Component Test!

Because we will most likely need our Store in every component we mount I recommend doing the following customization to your mount command:

// cypress/support/component.ts

import { mount } from 'cypress/angular'
import { AppModule } from 'src/app/app.module'

declare global {
  namespace Cypress {
    interface Chainable {
      mount: typeof mount
    }
  }
}

// This is necessary as mount takes a generic for it's first two arguments
type MountParams = Parameters<typeof mount>

Cypress.Commands.add(
  'mount',
  (component: MountParams[0], config: MountParams[1] = {}) => {
    return mount(component, {
      ...config,
      imports: [
        ...(config.imports || []),
        AppModule
      ]
    }
  }
)

Now every time we call cy.mount we are automatically importing AppModule. Now we can change our test back to how it was originally and we should get a successfully mounted Stepper Component.

describe('StepperComponent', () => {
  it('can mount', () => {
    cy.mount(StepperComponent)
  })
})

Beyond The Basics

Selectors
Though we have our component mounted we aren't running any assertions against it. Let's add a test validating that the count$ observable which is using our selectCount selector is working correctly by asserting the initial value of count is zero.

  it('has a correct default count of 0', () => {
    cy.mount(StepperComponent);
    cy.get('span').should('have.text', '0');
  });

Now let's test incrementing the count:

  it('can increment the count', () => {
    cy.mount(StepperComponent);
    cy.get('button').contains('+').click();
    cy.get('span').should('have.text', '1');
  });

And then decrementing the count:

  it('can decrement the count', () => {
    cy.mount(StepperComponent);
    cy.get('button').contains('-').click();
    cy.get('span').should('have.text', '-1');
  });

Finally let's test clearing the count:

  it('can clear the count', () => {
    cy.mount(StepperComponent);
    cy.get('button').contains('+').click().click();
    cy.get('span').should('have.text', '2');
    cy.get('button').contains('Clear').click();
    cy.get('span').should('have.text', '0');
  });

Now we should have 5 passing tests that are validating the various ways a user might interact with our Stepper Component.

Actions
Though we know our component appears to be working as expected, in less trivial use-cases we will want to test our component's integration with our store more thoroughly. Let's dive deeper into dispatched actions.

There are several ways of approaching writing tests for dispatching actions. Let me first start off with the less ideal implementation:

If we look at our Component we see that we are using Angular's click() event binding to call a public method in our component's class that eventually calls our store's dispatch method.

For example this button when clicked calls the increment() method in our component class:

<button (click)="increment()">+</button>

Then our component class increment method dispatches an incrementCount() action to our store:

private readonly store = inject(Store);

increment() {
  this.store.dispatch(incrementCount());
}

Because the increment method is a public property in our class we can easily write a test that asserts that it is called when the increment button is clicked:

  it('can spy on increment invocation', () => {
    cy.mount(StepperComponent).then(({ component }) => {
      cy.spy(component, 'increment').as('increment');
    });
    cy.get('button').contains('+').click();
    cy.get('@increment').should('have.been.calledOnce');
    cy.get('span').should('have.text', 1);
  });

We can then do the same thing for decrement, clear, etc.

Though this does validate that our button click is binding correctly to our methods it doesn't actually do any validating that a specific action is being dispatched. Let's try to take this same approach but apply it to our store's dispatch method.

  it('can spy on store.dispatch', () => {
    cy.mount(StepperComponent).then(({ component }) => {
      cy.spy(component.store, 'dispatch').as('dispatchSpy');
    });
    cy.get('button').contains('+').click();
    cy.get('@dispatchSpy').should('have.been.called');
  });

If you haven't already identified the issue with this test you should see the following error because our store property is a private field in our class.

Though we are getting this error, the test is actually correct and will pass when we run it. Let's manually swallow this TS error by adding a ts-expect-error comment

...
cy.mount(StepperComponent).then(({ component }) => {
  // @ts-expect-error
  cy.spy(component.store, 'dispatch').as('dispatchSpy');
});
...

We are now in business and can write tests validating specific actions are dispatched to our NgRx store. But let's make this even easier by writing a few custom commands!

Custom NgRx Store Commands

cy.store()
We first need an easy way to access our store since it is private in our components. Let's create a new custom command:

// cypress/support/component.ts

import { Store } from '@ngrx/store' 

declare global {
  namespace Cypress {
    interface Chainable {
      mount: typeof mount;
      store(storePropertyName: string): Cypress.Chainable<Store>;
    }
  }
}

Cypress.Commands.add(
  'store',
  { prevSubject: true },
  (subject: MountResponse<MountParams>, storePropertyName: string) => {
    const { component } = subject;

    // @ts-expect-error
    const store = component[storePropertyName] as Store;

    return cy.wrap(store);
  }
);

Now let's create a test using our new store command:

  it('can use cy.store()', () => {
    cy.mount(StepperComponent)
      .store('store')
      .then((store) => {
        cy.spy(store, 'dispatch').as('dispatchSpy');
      });

    cy.get('button').contains('+').click();
    cy.get('@dispatchSpy').should('have.been.called');
    cy.get('span').should('have.text', 1);
  });

Now we can easily access our store by just chaining off our our cy.mount() command. But let's go one step further and make spying on our dispatch easier by creating a dispatch command:

cy.dispatch()

// cypress/support/component.ts

import { Store } from '@ngrx/store' 

declare global {
  namespace Cypress {
    interface Chainable {
      mount: typeof mount;
      store(storePropertyName: string): Cypress.Chainable<Store>;
      dispatch(): Cypress.Chainable;
    }
  }
}

Cypress.Commands.add('dispatch', { prevSubject: true }, (store: Store) => {
  return cy.wrap(cy.spy(store, 'dispatch').as('dispatch'));
});

Now we can write a new test using both of our new commands:

  it('can use cy.dispatch()', () => {
    cy.mount(StepperComponent).store('store').dispatch();
    cy.get('button').contains('+').click();
    cy.get('@dispatch').should('have.been.called');
    cy.get('span').should('have.text', 1);
  });

TADA! We now can easily write Cypress Component Tests for our Components that are tied to an NgRx Store!

Conclusion:

Using Component Tests to write tests for your Angular Component's using NgRx Store is both super easy and creates high value tests. This article certainly doesn't cover everything that can be tested like this but hopefully paints a clear enough picture so you can see the power of using Cypress Component Testing with NgRx.

Testing Defer Blocks in Angular with Cypress

Jordan Powell — Thu, 21 Dec 2023 20:00:52 +0000

What is Defer anyways?

Deferrable views are one of the brand new exciting features that shipped as part of Angular 17 last month as part of the new "Angular Renaissance". This feature allows users to defer the loading of select dependencies within an angular component template.

This is important because it allows us to "defer" large components or sections of our code from the initial render of our application. This can improve your application Core Web Vital (CWV) results improving the initial load size and time to paint.

You can see a super trivial example of this in action below:

@defer() {
  <p>inside defer</p>
}

The Background

Recently I came across this issue while triaging some issues at Cypress. (Shout out to MattiaMalandrone for creating an issue with clear instructions for how to reproduce). After quickly replicating the issue I sought after a solution which ultimately inspired me to write this article.

You can download and follow along using this example repo

Get Started

Let's assume we want to test the AppComponent which has the following html:

<p>outside defer</p>

@defer() {
<p>inside defer</p>
} @defer(on timer(1000ms)) {
<p>inside defer with condition</p>
}

To begin we need to create a new file at src/app/app.component.cy.ts where we can write our first test.

import { AppComponent } from './app.component'

describe('AppComponent', () => {
  it('can mount', () => {
    cy.mount(AppComponent)
  })
})

Though writing our first test was super simple you may notice that none of the blocks of code inside of our @defer() blocks are rendered in the DOM. Thankfully the Angular 17 shipped with some testing utilities that we can utilize to not only gain access to those deferred blocks but also to render them in the DOM.

Next we will add support for both accessing the array of defer blocks and rendering the block in the DOM. Let's open our cypress/support/component.ts file and add the following code:

import { DeferBlockFixture, DeferBlockState } from '@angular/core/testing'

import { MountResponse, mount } from 'cypress/angular';

declare global {
  namespace Cypress {
    interface Chainable {
      mount: typeof mount;
      defer(): Cypress.Chainable<DeferBlockFixture[]>;
      render(state: DeferBlockState): Cypress.Chainable<void>
    }
  }
}

type MountParams = Parameters<typeof mount>;

Cypress.Commands.add('mount', mount);
Cypress.Commands.add(
  'defer',
  { prevSubject: true },
  (subject: MountResponse<MountParams>) => {
    const { fixture } = subject;
    return cy.wrap(fixture.getDeferBlocks());
  }
);

Cypress.Commands.add(
  'render',
  { prevSubject: true },
  (subject: DeferBlockFixture, state: DeferBlockState) => {
    cy.wrap(subject.render(state));
  }
);

Here we added 2 new Cypress Custom Commands defer and render which will allow us to test our blocks of code that use defer(). Now that we have our new Cypress global commands setup we can revisit our spec file to finish adding tests for the uncovered scenarios.

Let's first update our first test to validate that we see the outside defer by default and that we do NOT see the other 2 paragraphs wrapped inside the defer blocks.

it('can mount', () => {
    cy.mount(AppComponent);
    cy.contains('p', 'outside defer');
    cy.contains('p', 'inside defer').should('not.exist');
    cy.contains('p', 'inside defer with condition').should('not.exist');
  });

Now let's add tests for the other 2 scenarios using our new custom commands.

it('renders inside the defer block', () => {
    cy.mount(AppComponent).defer().its(0).render(DeferBlockState.Complete);
    cy.contains('p', 'outside defer');
    cy.contains('p', 'inside defer');
  });

In this example we can chain off our mount command and call our new defer command which returns an array of DeferBlockFixtures. We can then use .its to select a specific item from the array and call our second command render with the appropriate DeferBlockState we want to trigger. In our use-case we will want to use DeferBlockState.Complete.

You should now see both the "outside defer" paragraph and the "inside defer" paragraph in our test.

Now let's add a test for the second defer block that is tied to a timer.

it('renders inside the defer block with a condition', () => {
  cy.mount(AppComponent).defer().its(1).render(DeferBlockState.Complete);
    cy.contains('p', 'outside defer');
    cy.contains('p', 'inside defer with condition');
  });

Notice the only real difference here is that we are grabbing the second item from the list of deferred views and running the checks on it.

Finally let's create one more command in our support file that will render all the defer blocks automatically so we don't have to manually trigger a render for each defer block.


...

declare global {
  namespace Cypress {
    interface Chainable {
      mount: typeof mount;
      defer(): Cypress.Chainable<DeferBlockFixture[]>;
      render(state: DeferBlockState): Cypress.Chainable<void>;
      renderAll(state: DeferBlockState): Cypress.Chainable<DeferBlockFixture[]>;
    }
  }
}

...

Cypress.Commands.add(
  'renderAll',
  { prevSubject: true },
  (subject: DeferBlockFixture[], state: DeferBlockState) => {
    subject.forEach((deferBlock: DeferBlockFixture) => {
      deferBlock.render(state);
    });

    cy.wrap(subject);
  }
);

Now let's add a final test case which validates that all the content in our component is rendered including all defer blocks.

it('renders all defer blocks using renderAll()', () => {
    cy.mount(AppComponent).defer().renderAll(DeferBlockState.Complete);
    cy.contains('p', 'outside defer');
    cy.contains('p', 'inside defer');
    cy.contains('p', 'inside defer with condition');
  });

Now we will see our final test validating that the content outside of the defer blocks AND BOTH defer blocks is rendered successfully in the DOM!

Conclusion

As you can see that testing defer with Cypress Component Testing is super simple with just a few simple commands. I am really just scratching the surface in this example but feel free to view the official documentation from Angular on how to test defer blocks for more details.

Make Sure You Do This Before Switching To Signals

Jordan Powell — Mon, 20 Mar 2023 14:39:44 +0000

This time last year Standalone Component's were the talk of the Angular town. This year signals have replaced that buzz throughout the Angular Ecosystem. Though it will take some time for the introduction of signals into Angular's ecosystem to take hold, it is important for us to begin thinking about how these changes may or may not affect our applications. In fact, I am proposing one thing that everyone should do before switching to signals. But before I get to that, let's first learn what signals are.

What Are Signals Anyways?

For those interested in learning more, you can view this PR from the Angular team that introduces signals into Angular.

For some historical context, Signals are not a new concept. In fact they are the backbone of reactivity in SolidJS. The SolidJS documentation describes Signals as the following: "They contain values that change over time; when you change a signal's value, it automatically updates anything that uses it."

Ok, but how are Signals different that what we currently have in Angular? The simple answer for many is that they aren't much different from a practical standpoint. But if we dig a little deeper, we will find that Signals solve a long standing performance and architectural problem Angular has with it's current Change Detection mechanism. That mechanism is a library known as Zone.Js. Though it works today, it has some pretty significant performance issues in larger applications that have a lot of changing state. By switching to Signals, we can slowly remove the parts of our applications that depend upon Zone.js and replace them with Signals. This will in effect improve the overall performance across our applications.

Ok, but what about RxJs? RxJs is a huge part of the Angular Ecosystem! It is used for handling streams of asynchronous data in our applications. Thankfully, RxJs isn't going anywhere! Signals however, are being introduced to handle any and all synchronous state changes in our Angular applications. I like to think of it as a replacement for any non RxJs state.

In Short:

Async: RxJs
Sync: Signals

The Problem

Now that we know a little bit more about Signals and what problems they solve; let's talk about the one thing you should do before switching to them! Let's first look at the problem by looking at a simple example.

Signals affect our Application's state, which in most cases is the most difficult and complex part of our applications. In fact, we want to be REALLY certain that any changes we make aren't causing regression. The best way to assure against this is through automated testing. More specifically UI tests. However, many unit tests written for Angular Components using Karma will break in the process of switching to Signals. This is because they are often times coupled to the implementation of the Component itself.

Let me show you can example below of a simple Standalone CounterComponent:



import { AsyncPipe } from '@angular/common'; 
import { Component } from '@angular/core'; 
import { BehaviorSubject } from 'rxjs'

@Component({ 
  standalone: true,
  imports: [AsyncPipe],
  template: `
    <h3 id="count">Count: {{ count$ | async }}</h3>
    <div>
      <button id="decrement" (click)="decrement()">-</button>
      <button id="increment" (click)="increment()">+</button>
    </div>
  `
})
export class CounterComponent {
  private count = 0;
  private readonly _count = new BehaviorSubject(0);
  count$ = this._count.asObservable()

  increment(): void {
    this.count ++;
    this._count.next(this.count)
  }

  decrement(): void {
    this.count --;
    this._count.next(this.count)
  }
}

A typical Karma Unit Test for this component would look like the following:



import { ComponentFixture, TestBed } from '@angular/core/testing'; 
import { CounterComponent } from './counter.component';

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

  beforeEach(async () => {
    imports: [CounterComponent]
  }).compileComponents();

  fixture = TestBed.createComponent(CounterComponent);
  component = fixture.componentInstance;
  fixture.detectChanges();

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

  it('can increment the count', () => {
    const compiled = fixture.nativeElement as HTMLElement;
    const count = compiled.querySelector("#count");
    expect(count?.textContent).toContain(0);
    const button = fixture.debugElement.nativeElement.querySelector('#increment')
    button.click();
    fixture.detectChanges();
    expect(count?.textContent).toContain(1);
  });

  it('can decrement the count', () => {
    const compiled = fixture.nativeElement as HTMLElement;
    const count = compiled.querySelector("#count");
    expect(count?.textContent).toContain(0);
    const button = fixture.debugElement.nativeElement.querySelector('#decrement')
    button.click();
    fixture.detectChanges();
    expect(count?.textContent).toContain(-1);
  })
});

Now we can run our test to validate it works by running:



ng test --watch

We should now seeing the following output:

Now we can go ahead and refactor our component to use Signals:



import { Component, signal } from '@angular/core'; 

@Component({ 
  standalone: true,
  template: `
    <h3 id="count">Count: {{ count() }}</h3>
    <div>
      <button id="decrement" (click)="decrement()">-</button>
      <button id="increment" (click)="increment()">+</button>
    </div>
  `
})
export class CounterComponent {
  count = signal(0)

  increment(): void {
    this.count.update(c => c = c + 1);
  }

  decrement(): void {
    this.count.update(c => c = c - 1);
  }
}

Now if we return to our test we will continue to see the following output:

Though this example works, it isn't always this trivial. Let's revert those changes we just made and I will show you more complex unit tests that will eventually fail after switching to signals.



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

  beforeEach(async () => {
    imports: [CounterComponent]
  }).compileComponents();

  fixture = TestBed.createComponent(CounterComponent);
  component = fixture.componentInstance;
  fixture.detectChanges();

  it('increments count$ when calling increment()', () => {
    component.increment();
    component.count$.pipe(
        take(1)
    ).subscribe((value) => {
        expect(value).toEqual(1)
    })
  })

  it('decrements count$ when calling decrement()', () => {
    component.decrement();
    component.count$.pipe(
        take(1)
    ).subscribe((value) => {
        expect(value).toEqual(-1)
    })
  })

If we return to our RxJs implementation and run our tests we just wrote, we will see 5 successful tests passing.

But, if we refactor our CounterComponent to use signals again, we will now see the following error in our Code Editor.

As you can see, most tests that test the logic in our Component's class directly will inevitably fail after refactoring to signals. To avoid this issue and improve the overall developer experience and quality of our tests, let's add Cypress Component Tests

Getting Started With Component Testing

If you haven't already done so let's add Component Testing to our application.



npm i cypress -D

Now we can launch Cypress and click on Component Testing:



npx cypress open

Now you can simply follow Cypress's Configuration Wizard to setup Component Testing in your application (if you haven't already done so). You can follow my video below for a more detailed guide to getting started with Angular Component Testing.

Writing Cypress Component Tests

Now that we have Cypress Component Testing configured let's create a Cypress Component test for the CounterComponent.



import { CounterComponent } from "./counter.component"

describe('CounterComponent', () => {
  it('can mount and display an initial value of 0', () => {
    cy.mount(CounterComponent)
    cy.get('#count').contains(0)
  })

  it('can increment the count', () => {
    cy.mount(CounterComponent)
    cy.get('#increment').click()
    cy.get('#count').contains(1)
  })

  it('can decrement the count', () => {
    cy.mount(CounterComponent)
    cy.get('#decrement').click()
    cy.get('#count').contains(-1)
  })
})

Now we can run the counter.component.cy.ts spec and we should get the following:

Now let's go ahead and re-run our tests using the signals implementation and we will see the same result. Not only were the Cypress tests significantly easier to write, they also provide additional value that our Karma test runner did not. We are now able to interact with our component in our test runner itself and verify it's output (as opposed to a tiny green dot).

You can find this example repo at https://github.com/jordanpowell88/angular-counter

Conclusion

TLDR: Angular is on 🔥! Signals, Standalone, SSR and so much more. Though the impacts of Signals is yet to be known as of this writing, I think that the safest way forward is to use high quality UI tests.

Admittedly I am biased, but I believe that Cypress Component Tests are the best tool for this job. They are simpler to write and they encourage you to write the UI tests we talked about in this article. In the end, which tool you use is up to you and your team. The most important thing is that you feel confident that the side effects caused by refactoring to signals are caught before your users do!

How I Became A Google Developer Expert

Jordan Powell — Fri, 30 Sep 2022 13:18:31 +0000

Some History

7 years ago I made a pretty major career shift from doing full-time ministry (working at a Church) to becoming a full-time Software Engineer. I was well aware that this was not the traditional career trajectory of someone who worked at a church, but one I was willing and eager to make.

From that moment on I begin doing anything I could to learn how to write code. From YouTube videos, blogs and even a membership to Treehouse, I begin slowly learning how to write code. This journey was not easy in any way shape or form. I spent an in-measurable amount of time building "hello world" apps and debugging my broken code. But it was in this pain that I grew and eventually strengthened the mental muscles needed to build software.

It was the community work of other Google Developer Experts that I used to learn how to write code. It was the time they took away from their families to write that tutorial or to make that video course that kept me going when I wanted to just give up. Programming is hard and I wouldn't have made it without you all!

The hard work of other GDE's has always motivated me to give back to the community and to help others who are just like I was. I knew the pain. I knew the commitment. I knew the sacrifices and I have always wanted to help motivate those on the same journey.

As much a I wanted to help others, I had this sense of "imposter syndrome". I still felt like the underdog trying to learn from the pros. The little kid who just wanted to play with the big kids on the playground. That isn't an easy switch to "flip". But, sometimes you just need to look in the mirror to remind yourself that you are not the little kid anymore.

Eventually, I began to help mentor some Junior devs and even write a few blog articles. Before I knew it was contributing to open source projects like NgRx and giving online meetup talks. I even began attending conferences like ng-conf and codemash. The important thing wasn't "what" I was doing, but just that I was doing something. I could go on and on about "how" I got here and "who" helped me along the way, but the important thing is to just keep going. Don't give up and keep working hard.

Over the past 2 years, I have given dozens of meetup talks, contributed to many open source libraries, spoken at several in person conferences (no thanks to Covid) and actively mentored others along the way. It was this work that ultimately got me recognized by the community as someone who embodies what it means to be a GDE. Today I am happy to announce that I have officially joined the Google Developer Expert program!

What Is A GDE

Google Developer Expert status recognizes the outstanding developers who exhibit great expertise in one or more Google technologies and continue to share it with the developer community, as well as exceptional professionals in product strategy, UX/UI and marketing.

Experts are leaders, mentors and evangelists. They create content such as tutorials, code samples, books and blogs; they publish videos, drive community projects, and speak at large and small events; they engage in mentoring opportunities for startups and developers; and they provide valuable feedback to Google Product teams. These independent professionals bring their hands-on experience and practical knowledge in working with Google technologies to developer communities worldwide.

Thank You

Today was a day I dreamed about for many years. I wouldn't have made it here without the help of so many people in the community. I know I will forget many of you but here are just a few people that have helped me along this journey:

My Wife Ashley
My Mom & Dad
Wes Grimes
Krista Hoge
Sam Feree
Ryan Buening
Rob Molnar
Jon Rista
Adam Murray
Tracy Lee
Brandon Roberts
Ben Swartz

Introducing Angular Component Testing

Jordan Powell — Tue, 16 Aug 2022 19:36:00 +0000

Earlier this year, we announced our biggest release of Cypress ever. This introduced a new unified UI, faster test runs, and support for a new type of testing, Component Tests. This initial release included Component Testing support for both React and Vue with the plan to add additional framework support over the next few months. Today, we are happy to deliver on that promise by adding first-class support for Component Testing for Angular!

Read on to learn more about:

How Cypress Component Testing for Angular improves your testing experience with real-time browser rendering, intelligent feedback, and familiar ergonomics

Why Component Test with Cypress?

Cypress Component Testing provides a testable component workbench for you to quickly build and test any Angular component regardless of its complexity.

Though you can unit test Angular components today using Karma or Jest, Cypress Component Testing provides several main advantages. Here’s why:

The Cypress Test Runner is browser-based, which allows you to test-drive your component’s styles and API in an isolated way that you do not get with headless unit testing via a jsdom.
Separating the components from the rest of your website enforces component-driven development, for developing higher quality, more durable UIs faster and more efficiently.
Less code! That’s right, writing tests for your Angular components requires significantly less code and time than with Karma.

The Nuts & Bolts

One of the main differences between End-to-End and Component Testing is that unlike E2E testing, which relies on an existing server to serve your website that you visit, Component Testing relies on its own devServer to serve your Angular components. Once a server is established, we need a way to mount your Angular components to the DOM. Let’s take a look under the hood of these 2 main parts of Angular Component Testing.

Angular Dev Server

One of the things that makes Cypress Component Testing so powerful for Angular applications is that Angular follows a common convention that we can lean on to accurately configure your devServer. In fact, for most users it requires zero configuration at all! This is because we are able to read your angular.json file and determine everything we need to know to serve your component accurately and reliably. After updating to the most recent version of cypress via npm install cypress@latest, you can follow the Cypress Launchpad instructions that configures your angular application for component testing for you!

Sounds too easy to be true? Don’t worry, we prepared a quickstart guide to help walk you through setting up your project with Angular.

TL;DR – the configured devServer inside of the cypress.config.ts:

import { defineConfig } from 'cypress'

export default defineConfig({
  ...,
  component: {
    devServer: {
      framework: 'angular',
      bundler: 'webpack'
    },
    specPattern: 'src/**/*.cy.ts'
  }
})

Angular Mount

The second component (no pun intended) for getting started with Angular Component Testing in Cypress is a @cypress/angular mount function to mount your Angular component to the DOM. Thankfully the same Cypress Launchpad steps also handle the configuration of your mount function.

import { mount } from 'cypress/angular'

Cypress.Commands.add('mount', mount)

See the finished cypress/support/component.ts. This allows you to use cy.mount() in any component test without having to import {mount} from 'cypress/angular' in every spec file.

An important thing to note about the angular mount function is that it wraps around Angular’s own TestBed used for testing. This means you get to use the same ergonomically Angular nomenclature that you already use when testing. Let’s take a look at the @cypress/angular mount function’s API.

The mount function takes 2 properties: **the component you want to mount and a configuration used to configure the TestBed (amongst other things). Let’s first take a look at the first property of component.

Component is the class name (ie: ButtonComponent) or the template string itself (i.e.: <app-button></app-button>).

MountConfig actually extends the TestModuleMetadata used to configure your current angular tests. That means you declare, provide and import the same way you do in your Angular tests today!

const config: MountConfig<CardComponent> = {
  declarations: [IconComponent, ButtonComponent, ...],
  providers: [MyService, ...],
  imports: [SharedModule, ...],
  componentProperties: {
    // you can even access your components public properties and methods here
    // ie: @Input(), @Output(), etc
  }
}

Before & After

Ultimately your components will use the same angular TestBed you already know and love, and also allow you to run them in a real browser so you can interact with the component the way a real user would. This means that mounting components actually gets much simpler using significantly less code!

Let’s look at the simplest component test with Angular using Karma vs: Cypress.

Karma

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

import { ButtonComponent } from './button.component';

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

  beforeEach(waitForAsync(() => {
    TestBed.configureTestingModule({declarations: [ButtonComponent]}).compileComponents();
  }));

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

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

Cypress

import { ButtonComponent } from './button.component'

describe('ButtonComponent', () => {
  it('can mount', () => {
    cy.mount(ButtonComponent)
  }
}

Wrapping Up

For a complete list of updates in 10.5.0, please review our changelog. If this feature is helpful, or if you have other ideas or feedback, let us know on Github.

Want to learn more about Angular Component Testing? Check out our All About Angular with Cypress webinar. Our own Ely Lucas and myself will be demoing Component Testing in Angular, showing you how to migrate from Protractor to Cypress, and how to use the Cypress Schematic.

You can also catch our experts at Ng Conf, a 3-day immersion into everything Angular in Salt Lake City, Utah. We’ll see you there!

Migrating to Cypress 10

Jordan Powell — Wed, 01 Jun 2022 15:37:48 +0000

An Overview

On June 1, 2022 we released Cypress version 10.0 which includes two new major features:

A New User Interface with a Unified Testing Experience
Component Testing

In order to gain the benefits of these new features, it was necessary for us to change a few of the ways we were doing things in the past. This article walks you through those changes, to help make your experience upgrading to Cypress 10.0 as seamless as possible.

Feel free to follow along using this video as well:

Upgrading

Upgrading is simple and it just requires you to run the following in your project:

npm install -D cypress@latest

yarn add -D cypress@latest

Starting the Migration

All we need to do to kickoff our migration is running the following script:

npx cypress open

Once Cypress launches, you will be greeted by the following video from Cypress Staff Engineer, Jess Sach about some of the new features in Cypress 10.

Renaming Existing Specs

The first step renaming existing specs, will automatically rename and move your existing spec files to conform to the new 10.0 standards. This includes changing the default spec folder from cypress/integration to the new cypress/e2e folder. It also includes changing the default spec file extension from [filename].spec[.ext] to the new [filename].cy[.ext].

The table in each of the following steps provides a helpful before and after diff of each of the changes the Migrator will make in that step.

Renaming the Support File

The second step, automatically renames your existing support files. In 10.0, Cypress now serves different support files for both E2E and Component Testing. This step, essentially, renames the E2E support file from cypress/support/index.js to the new cypress/support/e2e.js

Migrate to the New Cypress Config

Finally, we will migrate our existing Cypress configuration, formerly cypress.json to the new Cypress configuration of cypress.config.js. This step is a little more detailed in that it not only renames the config file, but also seeds the new config with the corresponding options from the old.

At this point, you will see a "Welcome to Cypress" window and that E2E testing has been successfully configured in our project. However, you may also have noticed the option to add Component Testing. This is one of the exciting new features that ships with Cypress 10. Notice though that this testing type is labeled as Not Configured. Let's change that now.

Getting Started with Component Testing

Before we get started, It's important to note that the 10.0 release a Cypress add support for the following component testing frameworks:

Vue 2 & 3
Vue CLI 2 & 3
Nuxt
React
Create React App
Next.js

No need to worry if you don't see your applications framework listed, Cypress is working hard behind the scenes to add additional framework support, including Angular and others in the near future.

The first thing we need to do to enable Component Testing is to pick our front-end framework.

Once we selected the appropriate framework, we are now presented with the bundler or dev server we're using.

Next Cypress takes your answers to the previous two questions and provides the correct dev dependencies that need to be installed in your project. Simply copy the install script provided by the migration guide into your terminal and run.

Once all the needed dependencies have been installed in your application, you can proceed.

Finally, we are presented with an overview of all the files that will be added to the project. This includes an update to the following:

Cypress Config
Adding a cypress/support/component.js file
Adding a component-index.html file

After reviewing all of the updated files, all we need to do is select the browser of our choice and begin testing!

Recap

Hopefully you found this guide, the video and the Cypress migration tool helpful in migrating your project to Cypress 10.0. For more details on how to get started with Component Testing I recommend visiting this section in our docs.

I also recommend giving this video a watch as my coleague Robert does a dive into "How to Write Component Test with Cypress"

Cypress Workflows in Warp

Jordan Powell — Fri, 29 Apr 2022 16:28:22 +0000

Recently I was introduced to a new terminal app called Warp. I was a bit skeptical at first as I thought a terminal was pretty strait forward and wasn't sure what type of improvements could be made to one. After trying Warp, I can tell you I was happy to be wrong. They very accurately describe it as "The terminal for the 21st century"

If you aren’t already using Warp you can download it at warp.dev

After you install Warp, go ahead and launch it and open the Workflows panel.

Workflows are an easier way to execute and share commands within Warp. They are searchable by name, description, or command and are easily parameterized

Workflows can be accessed directly within Warp, either through the Command Palette or by pressing ctrl-shift-r

Once the Workflows panel is open you can then scroll to Cypress under Categories or just begin typing cypress.

We now get shortcuts for how to run and open Cypress. We can even pass in an optional parameter for viewport width and and height.

Finally if click open and you can now watch Warp open Cypress and run your tests!

To see this in action, you can watch the example video below:

Multi-Domain (Origin) Testing in Cypress

Jordan Powell — Mon, 25 Apr 2022 18:13:05 +0000

For as amazing as Cypress is for writing end-to-end tests, it has had a very long standing "issue" around visiting multiple origins in a single spec. I won't go into the details as to why this was the case in this article, but it is important to note that previously you had to rely upon other workarounds for testing scenarios that required this sort of behavior. This was most common when trying to visit a page that requires the user to be authenticated. Typically this would then redirect the user to a different domain or origin that handles authentication.

I am happy to announce that this is no longer an issue as today Cypress launched version 9.6.0 which adds support for cy.origin 🎉🎉🎉

Let's take a deep dive into how to use cy.origin in the real world. Let's create a test that visits our site locally at http://localhost:3000 and then clicks on a login button. Here is what a Cypress test would look like:

it("throws a cross origin error", () => {
  cy.visit("http://localhost:3000");
  cy.get("#qsLoginBtn").click()
  cy.get("#1-email").type(Cypress.env("EMAIL");
  cy.get("input[type='password']")
    .type(Cypress.env("PASSWORD"));
  cy.get("button[type='submit']").click()
})

If you run this test in Cypress it will throw an error that looks something like this:

No worries, because this problem is finally an easy one to solve with cy.origin.

Enabling Support

To enable this support you just need to add the following flag to your cypress.json

{
  "experimentalSessionAndOrigin": true
}

Now that we have enabled support for the cy.origin API, let's take a quick look into the way it works.

Syntax

cy.origin(url, callbackFn)
cy.origin(url, options, callbackFn)

Arguments

As you can see the cy.origin function expects 2 arguments with an optional third (middle) argument passed to it. Let me breakdown these arguments more in-depth:

url (String)

This argument specifies the secondary origin in which the callback will be executed.

options (Object)

This argument (the second and optional argument passed to the origin function) is a plain JavaScript object which will be serialized and sent from the primary origin to the secondary origin. From there it will be deserialized and passed into the callback function as its first and only argument. The args object is the only mechanism via which data may be injected into the callback as the callback is not a closure and does not retain access to the JavaScript context in which it was declared.

callbackFn (Function)

This argument contains the function containing Cypress commands to be executed in the secondary origin. Cypress will strigify this function and passed from the current Cypress instance to the secondary origin and evaluated.

Now that we have some more context as to how this works, let's add cy.origin to our previous test we wrote:

it("Logs in with Auth0", () => {
  cy.visit("http://localhost:3000/");
  cy.get("#qsLoginBtn").click();

  cy.origin("https://myusername.auth0.com/", () => {
    cy.get("#1-email").type(Cypress.env("EMAIL");
    cy.get("input[type='password']")
      .type(Cypress.env("PASSWORD"));
    cy.get("button[type='submit']").click()
  }

  cy.get("h1").should("contain", "React.js Sample Project");
})

Now if we re-run that same test we should now be getting a passing test!

Refactoring into Custom Commands

Now that we have cy.origin working in our app, it is time to think about reusability. Because having an authenticated user is a requirement for parts (or all of our app), we will need to login over and over. This is a great candidate for moving our login code into a Custom Cypress Command. Let's add the following code into our support/commands.js file.

Cypress.Commands.add("login", (email, password) => {
  cy.visit("http://localhost:3000/");
  cy.get("#qsLoginBtn").click();

  cy.origin(
    "https://myusername.auth0.com/",
    { args: [email, password] },
    ([email, password]) => {
      cy.get("#1-email").type(email);
      cy.get("input[type='password']").type(password);
      cy.get("button[type='submit']").click();
    }
  );

  cy.get("h1").should("contain", "React.js Sample Project");
});

As you can see, we are essentially just removing the code we were doing before inside of our test to the support/commands.js file. The only difference now, is that we are passing in an optional object with an args property to the cy.origin command. The arguments are an array containing an email and password property that are now being passed into our custom login command.

Now we can easily login to our app using our new cy.login custom command like so:

beforeEach(() => {
  cy.login(
    Cypress.env("EMAIL"),
    Cypress.env("PASSWORD")
  );
});

Now before each tests we write, we will now login using the cy.origin API via our custom login command. However, if your spec file contains more than one test, you will now notice an issue. Before every tests runs, we now have to wait for the browser to do this login work. This takes a considerable amount of time, especially the more tests you write. Thankfully we can improve this by using cy.session

Using cy.Session

Let's make a simple update to our cy.login command we just created by wrapping it with cy.session:

Cypress.Commands.add("login", (email, password) => {
  cy.session([email, password], () => {
    cy.visit("http://localhost:3000/");
    cy.get("#qsLoginBtn").click();

    cy.origin(
      "https://myusername.auth0.com/",
      { args: [email, password] },
      ([email, password]) => {
        cy.get("#1-email").type(email);
        cy.get("input[type='password']").type(password);
        cy.get("button[type='submit']").click();
      }
    );

    cy.get("h1").should("contain", "React.js Sample Project");
  });
});

By wrapping our cy.login command with cy.session this allows Cypress to cache all cookies, tokens and data from our session to be reused quickly in subsequent tests. As you can see all of our tests as passing and our tests run much faster now!

Conclusion

Hopefully you are as excited about this new experimental release of cy.session as we are here at Cypress. This feature not only solves the long standing challenge we've had around supporting multi-domain tests, but also makes things like logging in a breeze!

Check out this in-depth video of cy.session in action from my good pal Robert Guss:

Also, check out the Official Cypress Documentation for a more in-depth look into how cy.session works.

Typescript Support For Cypress

Jordan Powell — Fri, 12 Nov 2021 17:58:18 +0000

For someone who has worked with Typescript for the past 5+ years, I really miss it when it's not there. I find adding types to my javascript code a nice comfort. Writing automated tests with Cypress is no exception. With that being said, adding Typescript support to your Cypress applications is easy peasy!

Getting Started

Cypress ships with official type declarations for TypeScript. This allows you to write your tests in TypeScript. The first thing we need to do is install the typescript dependency.

yarn add --dev typescript

Next we need to update our tsconfig.json file with the following configuration:

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["es5", "dom"],
    "types": ["cypress"]
  },
  "include": ["**/*.ts"]
}

Finally we need to rename all of our .spec.js integration files to .spec.ts.

Custom Commands

If you are like me you've found the path to this point super simple! However, if your application is using Cypress's Custom Commands API your Cypress application is now angry.

Don't worry this is easy to fix! Let's open the file that contains our custom commands (usually support/commands.ts). This file should contain all of your commands as well as a Cypress namespace with a Chainable Interface. It is in this Interface we will add a reference to our custom command(s).

declare namespace Cypress {
  interface Chainable<Subject> {
    getBySel(selector: string): Chainable<Element>
  }
}

Cypress.Commands.add('getBySel', (selector: string, ...args: any[]): Cypress.CanReturnChainable => {
  return cy.get(`[data-test=${selector}]`, ...args)
})

And voilà our Cypress application is happy and now has full support for Typescript!

More Resources

Cypress Best Practices

Jordan Powell — Wed, 10 Nov 2021 18:57:05 +0000

Organizing Tests, Logging In, Controlling State

Anti-Pattern: Sharing page objects, using your UI to log in, and not taking shortcuts.
Best Practice: Test specs in isolation, programmatically log into your application, and take control of your application's state.

Selecting Elements

Anti-Pattern: Using highly brittle selectors that are subject to change.
Best Practice: Use data-* attributes to provide context to your selectors and isolate them from CSS or JS changes

Selector	Recommended	Notes
`cy.get('button').click()`	Never	Worst - too generic, no context
`cy.get('.btn.btn-large').click()`	Never	Bad. Coupled to styling. Highly subject to change
`cy.get('#main').click()`	Sparingly	Better. But still coupled to styling or JS event listeners.
`cy.get('[name=submission]').click()`	Sparingly	Coupled to the name attribute which has HTML semantics.
`cy.contains('Submit').click()`	Depends	Much better. But still coupled to text content that may change.
`cy.get('[data-cy=submit]').click()`	Always	Best. Isolated from all changes.

Assigning Return Values

Anti-Pattern: Trying to assign the return value of Commands with const, let, or var.
Best Practice: Use closures to access and store

Visiting External Sites

Anti-Pattern: trying to visit or interact with sites or servers you do not control
Best Practice: Only test what you control. Try to avoid requiring a 3rd party server. When necessary, always use cy.request() to talk to 3rd party servers via their APIs.

Having tests rely on the state of previous tests

Anti-Pattern: Coupling multiple tests together
Best Practice: Tests should always be able to be run independently from one another and still pass.

Creating "tiny" tests with a single assertion

Anti-Pattern: Acting like you're writing unit tests.
Best Practice: Add multiple assertions and don't worry about it

Using `after` or `afterEach` hooks

Anti-Pattern: Using after or afterEach hooks to clean up state.
Best Practice: Clean up state before tests run.

Unnecessary Waiting

Anti-Pattern: Waiting for arbitrary time periods using cy.wait(Number)
Best Practice: Use route aliases or assertions to guard Cypress from proceeding until an explicit condition is met

Web Servers

Anti-Pattern: Trying to start a web server from within Cypress scripts with cy.exec() or cy.task().
Best Practice: Start a web server prior to running Cypress

Setting a global baseUrl

Anti-Pattern: Using cy.visit() without setting a baseUrl.
Best Practice: Set a baseUrl in your configuration file (cypress.json by default)

You can read our entire Best Practices Guide at https://docs.cypress.io/guides/references/best-practices

Unit Testing in Angular - To TestBed or NOT to TestBed

Jordan Powell — Wed, 16 Sep 2020 11:01:50 +0000

I recently started consulting for a new client (no names please). As I began to create a new feature and write unit tests I noticed several things. First that writing tests were more difficult than necessary (I'll get into this more specifically later) and that the Test runner was running very slowly.

As I began to look deeper into the tests I noticed a difference between my unit tests and the previously written tests from other parts in the app. I discovered that I was using TestBed to create my tests. This wasn't the case anywhere else in the app. I found this to be very interesting as I've always used TestBed in the past and performance was not an issue.

This led me to do some more research on the topic and see if any others in the Angular Community were not using TestBed. I couldn't find many articles but was able to find an episode of The Angular Show podcast where Joe Eames and Shai Reznik were having a very healthy debate on why you should or shouldn't use TestBed. I won't spoil the episode for you but I will admit that for someone who works in Angular every day this was the first I had ever heard a case (and a good one at that) for not using TestBed.

Though I was still skeptical, I figured I would give it a shot on this project and see if it made a difference. I was quickly blown away by the increase in performance this approach brought me. This led me to ask the question of why...which ultimately led to this blog article.

Performance

When you remove TestBed from your component spec files it essentially no longer tests the DOM. It now only tests the component class itself. This felt like a code smell at first but ultimately the more I thought about it, the more I realized that a true unit test should only be testing one unit of code. How the component's HTML template interacted with its component class really becomes an integration test, testing the integration between the two.

So let me unpack this a little bit more. When you use the Angular CLI and generate a new component ng g c my-feature it will render the following files:

my-feature.component.html
my-feature.component.scss
my-feature.component.ts
my-feature.component.spec.ts

When you open up the my-feature.component.spec.ts file we see the following:

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

import { MyFeatureComponent } from './my-feature.component';

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

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

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

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

This essentially before each test will create a new instance of the MyFeatureComponent class and the DOM. This example is trivial but in an application with hundreds of components, generating the DOM for every test can become costly.

WITHOUT TestBed

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

import { MyFeatureComponent } from './my-feature.component';

describe('MyFeatureComponent', () => {
  let component: MyFeatureComponent;

  beforeEach(() => {
    component = new MyFeatureComponent()
  });

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

By just newing up the MyFeatureComponent class before each test it will just create the class instance and forgo the DOM itself.

What about Dependencies?

Let's say our component now has 2 dependencies. One to a UserService and another to a MyFeatureService. How do we handle writing tests that need dependencies provided?

WITH TestBed

@angular/core/testing';

import { MyFeatureComponent } from './my-feature.component';
import { UserService, MyFeatureService } from 'src/app/services';

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

  beforeEach(async(() => {
    TestBed.configureTestingModule({
      declarations: [ MyFeatureComponent ],
      providers: [UserService, MyFeatureService]
    })
    .compileComponents();
  }));

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

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

WTHOUT TestBed

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

import { MyFeatureComponent } from './my-feature.component';
import { UserService, MyFeatureService } from 'src/app/services';

describe('MyFeatureComponent', () => {
  let component: MyFeatureComponent;
  const userService = new UserService();
  const myFeatureService = new MyFeatureService();

  beforeEach(() => {
    component = new MyFeatureComponent(userService, myFeatureService);
  });

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

*** Note: The order of dependencies you add into the new Component class instance does need to be in the correct order with this approach.

What if my dependencies have dependencies?

I know you were probably thinking the same thing when looking at the previous example as most dependencies have other dependencies. For example, a service typically has a dependency upon HttpClient which enables it to make network requests to an API. When this happens (which is almost always) we typically use a mock or a fake.

WITH TestBed

@angular/core/testing';

import { MyFeatureComponent } from './my-feature.component';
import { UserService, MyFeatureService } from 'src/app/services';

class FakeMyFeatureService {

}

class FakeUserService {

}

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

  beforeEach(async(() => {
    TestBed.configureTestingModule({
      declarations: [ MyFeatureComponent ],
      providers: [
        { provide: UserService, useClass: FakeUserService },
        { provide: MyFeatureService, useClass: FakeMyFeatureService }
      ]
    })
    .compileComponents();
  }));

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

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

WITHOUT TestBed

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

import { MyFeatureComponent } from './my-feature.component';
import { UserService, MyFeatureService } from 'src/app/services';

class FakeMyFeatureService {

}

class FakeUserService {

}

describe('MyFeatureComponent', () => {
  let component: MyFeatureComponent;
  const userService = new FakeUserService();
  const myFeatureService = new FakeMyFeatureService();

  beforeEach(() => {
    component = new MyFeatureComponent(userService, myFeatureService);
  });

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

*** Note: You will want to use spies on those dependencies to actually test the parts of your component you care about.

Less Flaky Tests

Without TestBed, we are no longer testing the DOM itself which means that changes to the DOM will no longer break your tests. I mean how many times have you created a component somewhere in your Angular application all of a sudden tests start failing? This is because TestBed is creating the DOM beforeEach test. When a component and its dependencies are added its parent component will now fail.

Let's take a look at this more in-depth by creating a parent component called MyParentComponent with ng g c my-parent

Now let's take a look at the my-parent.component.spec.ts file:

WITH TestBed

@angular/core/testing';

import { MyParentComponent } from './my-parent.component';

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

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

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

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

WITHOUT TestBed

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

import { MyParentComponent } from './my-parent.component';

describe('MyParentComponent', () => {
  let component: MyParentComponent;

  beforeEach(() => {
    component = new MyParentComponent();
  });

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

Now let's add MyFeatureComponent to the template as a child of MyParentComponent.

<my-parent>
  <my-feature />
</my-parent>

In this example, my-parent.component.spec.ts tests are now all failing as it doesn't have a declaration for MyFeatureComponent or it's providers UserService and MyFeatureService. Below is now what we need to do to get those tests back up and passing.

WITH TestBed

@angular/core/testing';

import { MyParentComponent } from './my-parent.component';
import { MyFeatureComponent } from './my-feature/my-feature.component';
import { UserService, MyFeatureService } from 'src/app/services';

class FakeMyFeatureService {

}

class FakeUserService {

}

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

  beforeEach(async(() => {
    TestBed.configureTestingModule({
      declarations: [ MyParentComponent, MyFeatureComponent ],
      providers: [
        { provide: UserService, useClass: FakeUserService },
        { provide: MyFeatureService, useClass: FakeMyFeatureService }
      ]
    })
    .compileComponents();
  }));

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

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

WITHOUT TestBed

This requires no changes as changes to the template had no effect on the test suite!

Other Things To Consider

There are some tradeoffs we need to consider by not testing any part of the DOM. The biggest being that we are no longer testing the DOM or the integration between it and it's component class. In most cases, we don't particularly care that when a button is clicked we test that it calls a method on its component class. We tend to trust Angular's (click) event binding to just work. Therefore we mostly care that the method it calls actually works as expected. HOWEVER, because we are no longer testing this integration we no longer have the assurance that another developer on the team accidentally deletes that integration. Or that after refactoring that this particular button calls this specific method.

I do believe this can be a relatively small tradeoff and that this sort of test can be handled more appropriately using e2e tests. I would also mention that this is not an all or nothing approach to testing. In the instances in your application where you do want to test the integration between the template and its class, you can still use TestBed. You essentially just no longer get the benefits above for the parts that are now using TestBed.

Note: In this example the Angular app was running on Angular version 7. Angular 9 and later now render your applications using IVY which released with some performance improvements for TestBed.

Conclusion

As you can see from our trivial example, that by removing TestBed from our Angular components spec files we are able to improve the performance of our test runner and are able to remove some of the flakiness. Of course, the magnitude by which your test speed will improve will depend upon the size of your application and the way your application is built. Applications with very large components (which is a bigger code smell) will benefit the most from this approach. Ultimately the biggest benefit to writing tests without TestBed is that you are truly writing unit tests that should be easy to write, more reliable, and provide very quick feedback. The easier, more reliable, and quicker feedback you can get from writing tests the more you can leverage the benefits of unit tests.

Using NgRx actionsBlocklist

Jordan Powell — Fri, 12 Jun 2020 19:04:42 +0000

Often times as your NgRx applications grow the Redux DevTools actions log can get too noisy. In my particular instance, as my application grew, their became a large number of actions that fired that were not valuable for myself and the rest of my team during development. With the default maximum number of actions set to just 25 actions, the actions you really care about can quickly become lost during development and debugging. That is where actionsBlocklist comes to the rescue!

HOW TO DO IT

Assuming you have @ngrx/store-devtools already installed, just add the following config to the instrument method to your StoreDevtoolsModule in your app.module

StoreDevtoolsModule.instrument({
  name: 'Store Name',
  maxAge: 25,
  actionsBlocklist: [
    // actions go here as list of string
    userActions.Scroll.type,
    otherFeatureActions.NotImportantAction.type,
    // etc
  ]
})

WHEN TO MAYBE DO IT

To provide a little more context, my application was a single page application (SPA) form that dispatched an action on mouse scroll. So every-time the user scrolled up or down the page it could easily dispatch 25 or more actions. Those actions were important as various features in my application were selecting state based upon where in the application the user scrolled to. So, it wasn't that the actions weren't important but more specifically it wasn't providing value in the Redux DevTools Actions Log.

The following actions could be potential candidates to be added to actionsBlocklist:

Actions dispatched by scroll events
Repetitive actions dispatched with a low debounceTime()
When multiple actions are often dispatched together
Actions with no or very little side effects

WHEN YOU SHOULD NEVER DO IT

Keep in mind adding actions to your actionsBlocklist will in-fact block them from showing up in your DevTools. Which means it can become very confusing why an action isn't being dispatched (even though it really is). So only add actions that you are fairly certain you do not and will not want to see anymore.

The following actions are are things you do not want to add to actionsBlocklist:

Actions with side-effects
Actions that happen infrequently
Actions triggered by a user action

CONCLUSION

Ultimately, adding actions to the actionsBlocklist is something you shouldn't do until it becomes glaringly obvious when debugging your application with the Redux DevTools. Its something that will scream louder and louder the more your application grows. It will almost beg you to add it!

Other alternatives to consider would be to filter the actions log in the DevTools for the actions you care about (as long as they are within your configured maximum number of actions).

Finally another thing to consider is to add actions to the actionBlocklist temporarily during debugging to really find the actions you care about (to fix your temporary problem). Note: Don't forget to remove them before checking in your code to source control

DEV Community: Jordan Powell

Testing NgRx Store with Cypress Component Testing

What is NgRx

Cypress Component Testing

Creating Our Store

Writing our First Test

Beyond The Basics

Custom NgRx Store Commands

Conclusion:

Testing Defer Blocks in Angular with Cypress

What is Defer anyways?

The Background

Get Started

Conclusion

Make Sure You Do This Before Switching To Signals

What Are Signals Anyways?

In Short:

The Problem

Getting Started With Component Testing

Writing Cypress Component Tests

Conclusion

How I Became A Google Developer Expert

Some History

What Is A GDE

Thank You

Introducing Angular Component Testing

Why Component Test with Cypress?

The Nuts & Bolts

Angular Dev Server

Angular Mount

Before & After

Wrapping Up

Migrating to Cypress 10

An Overview

Upgrading

Starting the Migration

Renaming Existing Specs

Renaming the Support File

Migrate to the New Cypress Config

Getting Started with Component Testing

Recap

Cypress Workflows in Warp

Multi-Domain (Origin) Testing in Cypress

Enabling Support

Syntax

Arguments

url (String)

options (Object)

callbackFn (Function)

Refactoring into Custom Commands

Using cy.Session

Conclusion

Typescript Support For Cypress

Getting Started

Custom Commands

More Resources

Cypress Best Practices

Organizing Tests, Logging In, Controlling State

Selecting Elements

Assigning Return Values

Visiting External Sites

Having tests rely on the state of previous tests

Creating "tiny" tests with a single assertion

Using after or afterEach hooks

Unnecessary Waiting

Web Servers

Setting a global baseUrl

Unit Testing in Angular - To TestBed or NOT to TestBed

Performance

WITHOUT TestBed

What about Dependencies?

WITH TestBed

WTHOUT TestBed

What if my dependencies have dependencies?

WITH TestBed

WITHOUT TestBed

Less Flaky Tests

WITH TestBed

WITHOUT TestBed

WITH TestBed

Using `after` or `afterEach` hooks