Gain insights into testing functions and classes, mocking dependencies, naming tests, testing asynchronous code, Node.js code, and browser API-dependent code using Jasmine in your JavaScript app.

Using Jasmine to Unit Test Your JavaScript App.png

dockerfile.v6.tar.gz

Run jasmine

live Jasmine

Live jasmine in unit-testing-course folder

Run jasmine flat

Run jasmine --config=./jasmine.json

Once jasmine

Run jasmine-browser-runner console

Run jasmine-browser-runner console-copy

Run jasmine-browser-runner serve

Run jasmine-browser-runner serve 3000

This course will teach learners how to test functions and classes, mock dependencies, name the tests, test asynchronous code, test Node.js code, and test browser API-dependent code.

Using Jasmine to Unit Test Your JavaScript App

We’ll be looking at class-based single-page application (SPA) components. [Angular](https://angular.io/guide/component-overview#creating-a-component-manually), [React](https://reactjs.org/docs/state-and-lifecycle.html#adding-local-state-to-a-class), and [Vue](https://class-component.vuejs.org/) all support class-based components.

SPA components generally expose lifecycle hooks (or methods) that can be used to do specific actions at certain times. For example, wait until the component is initialized (or mounted/displayed) before making a call to the API to fetch some data. And at the time of its destruction (or unmount), stop any further processing.

Click the following links for examples of component lifecycle hooks from the aforementioned SPA frameworks:
:

- [Angular docs](https://angular.io/guide/lifecycle-hooks#initializing-a-component-or-directive)
- [React docs](https://reactjs.org/docs/react-component.html#componentdidmount)
- [Vue docs](https://vuejs.org/v2/api/#mounted)

# 'ArticleComponent'

For this lesson, we’ll use an SPA component that displays an article, like in a blog. It loads the article at the time of its initialization. At the time of its destruction, it marks itself destroyed and doesn’t show the article.

In the code playground below, there’s an implementation of `ArticleComponent` and its tests. Let’s run them and see their breakdown below.


React

Dart

GoJS React

Typescript React

Vue.js

# 'ArticleComponent' Breakdown

Looking at the `src/article.component.mjs`, we see the following:


- ```js
  export class ArticleComponent {
    articleId; // or props.articleId

    article;
    loading;
    destroyed;
    //...
  }
  ```

  We start by declaring the class of the component and declaring some properties in it:
- The `articleId` is the `id` of the article the component is to display. This is expected to be an input (or prop). That is, the component relies on it being there to do its job. Click the following links for examples of [Angular Input](https://angular.io/guide/inputs-outputs#sending-data-to-a-child-component), [React props](https://reactjs.org/docs/components-and-props.html#rendering-a-component), and [Vue props](https://v3.vuejs.org/guide/component-props.html#passing-static-or-dynamic-props).
- The `article` holds a reference to the article object that is fetched from the `ArticleAPI`.
- The `loading` property lets us show and hide a loading spinner. This lets the user know something is going on in the background. 
- The `destroyed` property becomes true when the component is being destroyed. That serves as the signal to stop any further processing.


- ```js
  articleAPI;
  userMessenger;

  constructor(articleApi, userMessenger) {
    this.articleAPI = articleApi;
    this.userMessenger = userMessenger;
  }
  ```

  - The `articleAPI` is the instance that lets us call the server API endpoint to get the article or delete it.
- The `userMessenger` is an instance of the `UserMessenger` class that shows a message to the user. It can be of the `info` or `error` category using the correspondingly named method of that class.
- In the `constructor`, we populate the `articleAPI` and the `userMessenger` properties with the passed-in instances.

 ```js
  async afterComponentInitialize() {
    this.loading = true;
    try {
      const article = await this.articleAPI.get(this.articleId);
      if(!this.destroyed) {
        this.article = article;
      }
    } catch {
      if(!this.destroyed) {
        this.userMessenger.error(`Could not fetch article id: "${this.articleId}". Please try again.`);
      }
    }
    this.loading = false;
  }
  ```

  This method is a hook that’s called by the framework (such as Angular or React) after the component initializes and is ready to take the data and display it. It’s an `async` method that allows us to use `await` within it.

The `this.loading = true;` line sets up the loading state so that a user sees a spinner indicating something is going on in the background.

- ```js
  try {
    const article = await this.articleAPI.get(this.articleId);
    if (!this.destroyed) {
      this.article = article;
    }
  }
  ```

 Wrapping the logic in a try-catch to check if the API call throws, we catch the error and handle it (handling logic is next).

The `this.articleAPI.get(this.articleId)` call is asynchronous (it returns a `Promise`), so we `await` it and get the response in the `article` local constant.

If the component gets destroyed, there is no point in populating the article property, so we skip it. This check is largely unnecessary for such a straightforward component logic. It demonstrates the “stop calculating after component destruction” approach, which cancels further calculations and stops potential memory leaks.

In essence, this check is here so we can demo how to test such logic.

- ```js
  try {
    // ... skipped
  } catch {
    if (!this.destroyed) {
      this.userMessenger.error(`Could not fetch article id: "${this.articleId}". Please try again.`);
    }
  }
  ```

  If the server returns an error (`400` or `500`), we expect the `Promise` to get rejected. We handle that case by showing relevant information to the user and potentially how to resolve this situation.

Again, we wrap this logic in a check to see if the component is still alive. This check is to handle a case similar to:

- The user opens the article.
- The spinner appears.
- The response takes a lot of time, and the spinner stays.
- The user closes the article component (for example, navigates back).
- The component gets destroyed at this time.
- The response arrives after that and is an error (`500`).

Showing an error at this time is confusing for the user if they’re in a different context now (for example, the article list page). So, we check if the component is still alive before showing the error.

- ```js
  beforeComponentDestroy() {
    this.destroyed = true;
    this.article = undefined;
  }
  ```

  This method is the hook that the framework calls when component destruction is about to happen. After this call, the framework removes the component from the DOM and discards it.


We mark this component instance as `destroyed` and discard any `article` object the component might hold a reference to, thus resetting it.

# Asynchronous challenges

There’s a new challenge for the tests: the hook method
`beforeComponentDestroy` can change the behavior of the 
`afterComponentInitialize` method while `afterComponentInitialize` is executing. Here’s how such a change might happen:

- The user clicks on an article to see its details.
- The framework creates the `ArticleComponent` and calls the `afterComponentInitialize` method, which starts executing.
- It reaches the line `const article = await` `this.articleAPI.get(this.articleId);` (line 19) and sends a request to the server to fetch the articles. That request may take anywhere from a hundred milliseconds to several seconds.

- The request takes more than five seconds, so the user is frustrated and hits the “Back” button.
- The framework calls the `beforeComponentDestroy` hook because it’s about to replace it with another, thereby “navigating” to a new page. (The single-page applications don’t actully navigate. They destroy the displayed component and replace it with another).

The nature of HTTP calls is asynchronous, as is a lot of the interaction on a web application, so this kind of asynchronous challenge comes up a lot. Let’s see how to test that.


# Tests breakdown

We’ll test the two hook methods. Let’s look at `spec/article-component.spec.mjs`:

- ```js
  import { ArticleComponent } from '../__src__/article.component.mjs';
  ```

  We start by importing the `ArticleComponent`.

- ```js
  describe('ArticleComponent', () => {
    let component;
    let articleAPI;
    let userMessenger;
  ```

  We define a test suite `ArticleComponent`.

- ```js
  let component;
  let articleAPI;
  let userMessenger;

  beforeEach(() => {
    articleAPI = jasmine.createSpyObj('article API', {
      get: Promise.resolve({ id: 1, title: 'first', content: 'article' }),
    });
    userMessenger = jasmine.createSpyObj('userMessenger', ['info', 'error']);
    component = new ArticleComponent(articleAPI, userMessenger);
  });
  ```

  We define some variables that are available for every test. They get reset before each test in the `beforeEach` Jasmine hook.

- The `articleAPI` uses a different `createSpyObj` method overload, which allows us to define the default response. In this case, we instruct Jasmine to create a spy for the `get` method of the ArticleAPI instance and return a `Promise` resolving to an article.
- The `userMessenger` is also a spy object, and it defines multiple methods for Jasmine to spy on `[‘info’, ‘error’]`.
- The component is reset to a new instance before every test, making each test separate and independent of the rest.


**Test case 1**


```js
it(`when initialized it should call the articleAPI get and assign the result to the article property`, async () => {
  // arrange
  component.articleId = 1;
  // act
  Await component.afterComponentInitialize();
  // Assert
  expect(articleAPI.get).toHaveBeenCalledOnceWith(1);
  expect(component.article).toEqual(jasmine.objectContaining({ id: 1 }));
});
```

The above test case ensures the article is assigned to the article property of the component when the server response arrives:

- We provide the component with an article `id`.
- We call the `afterComponentInitialize` method, simulating what a framework does.
- We make sure that `get` is called with the expected `id`, and the article returned is an object that contains the `id: 1` in it.
  - The object properties id: 1, title: ... were set in the default response for get in beforeEach above and not in the test itself.


**Test case 2**


```js
it(`when initialized it should call the articleAPI get and inform user upon article fetch failed`, async () => {
  // Arrange
  component.articleId = 1;
  articleAPI.get.and.returnValue(Promise.reject('error'));
  // act
  Await component.afterComponentInitialize();
  // Assert
  expect(userMessenger.error).toHaveBeenCalledOnceWith('Could not fetch article id: "1". Please try again.');
});
```

The above test case ensures that the user gets notified of an error via the `userMessenger.error` method when an error happens (that is, when the response is `4xx` or `5xx`):

- We provide the component with an article id.
- We provide `articleAPI.get` a `Promise` that is rejected. That’s the failing scenario.
- We call the `returnValue`.
- We assert that the `error` method of `userMessenger` is called as expected.


**Test case 3**

```js
it(`when initialized it should set loading to true and back to false after the article response arrives`, async () => {
  // Arrange
  articleAPI.get.and.returnValue(Promise.resolve({ id: 1 }));
  component.articleId = 1;
  // Act
  const initPromise = component.afterComponentInitialize();
  // Assert
  expect(component.loading).toBe(true);
  await initPromise;
  expect(component.loading).toBe(false);
});
```

The above test case ensures that loading is `true` while the component waits for the article to arrive, and then it turns to `false`:

- We start by providing the return value `Promise.resolve({id: 1})`. Since it’s valuable for the outcome of the test, we explicitly provide it. It’s valuable because if the `Promise` rejects, the test fails.

- We need to control when the `Promise` resolves, which is when the server responds, so that we’re able to verify that `loading` is `true` in the meantime.
- We store the `Promise` in the `initPromise` local constant and don’t `await` it until we’ve asserted that the value of `loading` is `true`.
- We assert that `loading` is `true`.
- We use `await initPromise`, simulating the wait until the response arrives, and assert that `loading` is now `false`.

**Test case 4**


```js
it(`when initialized it should set loading to true and back to false even after article fetch fails`, async () => {
  // Arrange
  articleAPI.get.and.returnValue(Promise.reject({ message: 'error' }));
  component.articleId = 1;
  // Act
  const initPromise = component.afterComponentInitialize();
  // Assert
  expect(component.loading).toBe(true);
  await initPromise;
  expect(component.loading).toBe(false);
});
```

The above test case ensures that loading behaves correctly in case of an error. It turns true while waiting for the response and false when the response arrives:

- We provide a rejected `Promise`as the `articleAPI.get` response.
- We store the Promise in the `initPromise` constant and don’t await it.
- We assert that `loading` is `true` while waiting for the response.
- We use await `initPromise` to simulate the response arriving.
- We assert that `loading` is now `false` even though an error happened.


**Test case 5**


```js
it(`when destroyed it should not set the article property`, async () => {
  // Arrange
  component.articleId = 1;
  articleAPI.get.and.returnValue(
    Promise.resolve({ id: 1, title: 'will not be shown to user because the component was destroyed' })
  );
  const initPromise = component.afterComponentInitialize();
  // Act
  component.beforeComponentDestroy();
  await initPromise;
  // Assert
  expect(component.article).toBeUndefined();
});
```

The above test case ensures that the article property doesn’t get populated in a destroyed component. That simulates a case where the user decides to navigate away from the current page, and while the new page intent is getting processed by the routing logic, the article response arrives. In that case, we don’t want to show the article information for a split second and then close it because it might cause a flash of content issue.

- We provide a good response by the articleAPI.get.
- We call `afterComponentInitialize` and store its result, the `initPromise`, in a constant and don’t `await` it. That allows us to destroy the component before the response arrives, simulating the second part of the condition above.
- We call beforeComponentDestroy to simulate the first part of the condition above.
- We use `await initPromise`, simulating the response arriving.
- We assert that the `article` property is indeed `undefined` as expected.


**Test case 6**


```js
it(`when destroyed it should not inform user upon article fetch failed`, async () => {
  // arrange
  component.articleId = 1;
  articleAPI.get.and.returnValue(Promise.reject('error'));
  const initPromise = component.afterComponentInitialize();
  // act
  component.beforeComponentDestroy();
  await initPromise;
  // assert
  expect(userMessenger.error).not.toHaveBeenCalledOnceWith('Could not fetch article id: "1". Please try again.');
});
```

The above test case ensures that the user is not notified of an error after they’ve decided to navigate away from this component (for example, if the response took too long and timed out):

- We provide a rejected `Promise` to the `articleAPI.get`, simulating the timed-out response.
- We invoke `afterComponentInitialize` and store its result (the `Promise`) in the `initPromise` response to `await` it later.
- We invoke `beforeComponentDestroy` to simulate the user navigating away and the framework destroying the component.
- We use await `initPromise` to simulate the server response arrival.
- We assert the the `error` method was not called.


# Exercise

For this lesson’s exercise, a delete article process with confirmation is added to the ArticleComponent in the form of three methods (see the code playground below). That implements a requirement to get the user’s confirmation before actually deleting an article. The process steps look like this:

1. The user clicks the “Delete” button on the article.
2. A dialog appears with a disclaimer that says, “Are you sure you want to delete the article …?” and two buttons: “Confirm” and “Cancel.”
3. The user either confirms and deletes the article, or cancels and backs out.


Find and finish the tests in `spec/article-component.spec.mjs` in the code playground below. They’re in a nested describe (`fdescribe`) test suite. Nesting `describe` in `describe` allows for some logical grouping of tests. The nested `describe` is an `fdescribe` that tells Jasmine to focus on this `describe` and only perform its tests. This is so that the rest of the tests don’t clutter the exercise ones. Feel free to leave it as is or replace it with a `describe` at any time.


There are a few tests for this exercise:

- When `onDeleteArticle` is invoked, the dialog `showDeleteArticleConfirmationDialog === true` should be shown.
- When `onDeleteArticle` gets invoked, and then `onDeleteArticleCancel` is invoked, a call to the `delete` method on the API does NOT happen. And the dialog `showDeleteArticleConfirmationDialog` should be hidden.

- When `onDeleteArticle` and then `onDeleteArticleConfirm` get invoked, a call to the delete method on the API happens. The info method on the `userMessenger` should also be called with a specific message.


If stuck, see the hints below.

# 'ArticleComponent' Breakdown

Looking at the `src/article.component.mjs`, we see the following:


- ```js
  export class ArticleComponent {
    articleId; // or props.articleId

    article;
    loading;
    destroyed;
    //...
  }
  ```

  We start by declaring the class of the component and declaring some properties in it:
- The `articleId` is the `id` of the article the component is to display. This is expected to be an input (or prop). That is, the component relies on it being there to do its job. Click the following links for examples of [Angular Input](https://angular.io/guide/inputs-outputs#sending-data-to-a-child-component), [React props](https://reactjs.org/docs/components-and-props.html#rendering-a-component), and [Vue props](https://v3.vuejs.org/guide/component-props.html#passing-static-or-dynamic-props).
- The `article` holds a reference to the article object that is fetched from the `ArticleAPI`.
- The `loading` property lets us show and hide a loading spinner. This lets the user know something is going on in the background. 
- The `destroyed` property becomes true when the component is being destroyed. That serves as the signal to stop any further processing.


- ```js
  articleAPI;
  userMessenger;

  constructor(articleApi, userMessenger) {
    this.articleAPI = articleApi;
    this.userMessenger = userMessenger;
  }
  ```

  - The `articleAPI` is the instance that lets us call the server API endpoint to get the article or delete it.
- The `userMessenger` is an instance of the `UserMessenger` class that shows a message to the user. It can be of the `info` or `error` category using the correspondingly named method of that class.
- In the `constructor`, we populate the `articleAPI` and the `userMessenger` properties with the passed-in instances.

 ```js
  async afterComponentInitialize() {
    this.loading = true;
    try {
      const article = await this.articleAPI.get(this.articleId);
      if(!this.destroyed) {
        this.article = article;
      }
    } catch {
      if(!this.destroyed) {
        this.userMessenger.error(`Could not fetch article id: "＄{this.articleId}". Please try again.`);
      }
    }
    this.loading = false;
  }
  ```

  This method is a hook that’s called by the framework (such as Angular or React) after the component initializes and is ready to take the data and display it. It’s an `async` method that allows us to use `await` within it.

The `this.loading = true;` line sets up the loading state so that a user sees a spinner indicating something is going on in the background.

- ```js
  try {
    const article = await this.articleAPI.get(this.articleId);
    if (!this.destroyed) {
      this.article = article;
    }
  }
  ```

 Wrapping the logic in a try-catch to check if the API call throws, we catch the error and handle it (handling logic is next).

The `this.articleAPI.get(this.articleId)` call is asynchronous (it returns a `Promise`), so we `await` it and get the response in the `article` local constant.

If the component gets destroyed, there is no point in populating the article property, so we skip it. This check is largely unnecessary for such a straightforward component logic. It demonstrates the “stop calculating after component destruction” approach, which cancels further calculations and stops potential memory leaks.

In essence, this check is here so we can demo how to test such logic.

- ```js
  try {
    // ... skipped
  } catch {
    if (!this.destroyed) {
      this.userMessenger.error(`Could not fetch article id: "＄{this.articleId}". Please try again.`);
    }
  }
  ```

  If the server returns an error (`400` or `500`), we expect the `Promise` to get rejected. We handle that case by showing relevant information to the user and potentially how to resolve this situation.

Again, we wrap this logic in a check to see if the component is still alive. This check is to handle a case similar to:

- The user opens the article.
- The spinner appears.
- The response takes a lot of time, and the spinner stays.
- The user closes the article component (for example, navigates back).
- The component gets destroyed at this time.
- The response arrives after that and is an error (`500`).

Showing an error at this time is confusing for the user if they’re in a different context now (for example, the article list page). So, we check if the component is still alive before showing the error.

- ```js
  beforeComponentDestroy() {
    this.destroyed = true;
    this.article = undefined;
  }
  ```

  This method is the hook that the framework calls when component destruction is about to happen. After this call, the framework removes the component from the DOM and discards it.


We mark this component instance as `destroyed` and discard any `article` object the component might hold a reference to, thus resetting it.

# Asynchronous challenges

There’s a new challenge for the tests: the hook method
`beforeComponentDestroy` can change the behavior of the 
`afterComponentInitialize` method while `afterComponentInitialize` is executing. Here’s how such a change might happen:

- The user clicks on an article to see its details.
- The framework creates the `ArticleComponent` and calls the `afterComponentInitialize` method, which starts executing.
- It reaches the line `const article = await` `this.articleAPI.get(this.articleId);` (line 19) and sends a request to the server to fetch the articles. That request may take anywhere from a hundred milliseconds to several seconds.

- The request takes more than five seconds, so the user is frustrated and hits the “Back” button.
- The framework calls the `beforeComponentDestroy` hook because it’s about to replace it with another, thereby “navigating” to a new page. (The single-page applications don’t actully navigate. They destroy the displayed component and replace it with another).

The nature of HTTP calls is asynchronous, as is a lot of the interaction on a web application, so this kind of asynchronous challenge comes up a lot. Let’s see how to test that.


# Tests breakdown

We’ll test the two hook methods. Let’s look at `spec/article-component.spec.mjs`:

- ```js
  import { ArticleComponent } from '../__src__/article.component.mjs';
  ```

  We start by importing the `ArticleComponent`.

- ```js
  describe('ArticleComponent', () => {
    let component;
    let articleAPI;
    let userMessenger;
  ```

  We define a test suite `ArticleComponent`.

- ```js
  let component;
  let articleAPI;
  let userMessenger;

  beforeEach(() => {
    articleAPI = jasmine.createSpyObj('article API', {
      get: Promise.resolve({ id: 1, title: 'first', content: 'article' }),
    });
    userMessenger = jasmine.createSpyObj('userMessenger', ['info', 'error']);
    component = new ArticleComponent(articleAPI, userMessenger);
  });
  ```

  We define some variables that are available for every test. They get reset before each test in the `beforeEach` Jasmine hook.

- The `articleAPI` uses a different `createSpyObj` method overload, which allows us to define the default response. In this case, we instruct Jasmine to create a spy for the `get` method of the ArticleAPI instance and return a `Promise` resolving to an article.
- The `userMessenger` is also a spy object, and it defines multiple methods for Jasmine to spy on `[‘info’, ‘error’]`.
- The component is reset to a new instance before every test, making each test separate and independent of the rest.


**Test case 1**


```js
it(`when initialized it should call the articleAPI get and assign the result to the article property`, async () => {
  // arrange
  component.articleId = 1;
  // act
  Await component.afterComponentInitialize();
  // Assert
  expect(articleAPI.get).toHaveBeenCalledOnceWith(1);
  expect(component.article).toEqual(jasmine.objectContaining({ id: 1 }));
});
```

The above test case ensures the article is assigned to the article property of the component when the server response arrives:

- We provide the component with an article `id`.
- We call the `afterComponentInitialize` method, simulating what a framework does.
- We make sure that `get` is called with the expected `id`, and the article returned is an object that contains the `id: 1` in it.
  - The object properties id: 1, title: ... were set in the default response for get in beforeEach above and not in the test itself.


**Test case 2**


```js
it(`when initialized it should call the articleAPI get and inform user upon article fetch failed`, async () => {
  // Arrange
  component.articleId = 1;
  articleAPI.get.and.returnValue(Promise.reject('error'));
  // act
  Await component.afterComponentInitialize();
  // Assert
  expect(userMessenger.error).toHaveBeenCalledOnceWith('Could not fetch article id: "1". Please try again.');
});
```

The above test case ensures that the user gets notified of an error via the `userMessenger.error` method when an error happens (that is, when the response is `4xx` or `5xx`):

- We provide the component with an article id.
- We provide `articleAPI.get` a `Promise` that is rejected. That’s the failing scenario.
- We call the `returnValue`.
- We assert that the `error` method of `userMessenger` is called as expected.


**Test case 3**

```js
it(`when initialized it should set loading to true and back to false after the article response arrives`, async () => {
  // Arrange
  articleAPI.get.and.returnValue(Promise.resolve({ id: 1 }));
  component.articleId = 1;
  // Act
  const initPromise = component.afterComponentInitialize();
  // Assert
  expect(component.loading).toBe(true);
  await initPromise;
  expect(component.loading).toBe(false);
});
```

The above test case ensures that loading is `true` while the component waits for the article to arrive, and then it turns to `false`:

- We start by providing the return value `Promise.resolve({id: 1})`. Since it’s valuable for the outcome of the test, we explicitly provide it. It’s valuable because if the `Promise` rejects, the test fails.

- We need to control when the `Promise` resolves, which is when the server responds, so that we’re able to verify that `loading` is `true` in the meantime.
- We store the `Promise` in the `initPromise` local constant and don’t `await` it until we’ve asserted that the value of `loading` is `true`.
- We assert that `loading` is `true`.
- We use `await initPromise`, simulating the wait until the response arrives, and assert that `loading` is now `false`.

**Test case 4**


```js
it(`when initialized it should set loading to true and back to false even after article fetch fails`, async () => {
  // Arrange
  articleAPI.get.and.returnValue(Promise.reject({ message: 'error' }));
  component.articleId = 1;
  // Act
  const initPromise = component.afterComponentInitialize();
  // Assert
  expect(component.loading).toBe(true);
  await initPromise;
  expect(component.loading).toBe(false);
});
```

The above test case ensures that loading behaves correctly in case of an error. It turns true while waiting for the response and false when the response arrives:

- We provide a rejected `Promise`as the `articleAPI.get` response.
- We store the Promise in the `initPromise` constant and don’t await it.
- We assert that `loading` is `true` while waiting for the response.
- We use await `initPromise` to simulate the response arriving.
- We assert that `loading` is now `false` even though an error happened.


**Test case 5**


```js
it(`when destroyed it should not set the article property`, async () => {
  // Arrange
  component.articleId = 1;
  articleAPI.get.and.returnValue(
    Promise.resolve({ id: 1, title: 'will not be shown to user because the component was destroyed' })
  );
  const initPromise = component.afterComponentInitialize();
  // Act
  component.beforeComponentDestroy();
  await initPromise;
  // Assert
  expect(component.article).toBeUndefined();
});
```

The above test case ensures that the article property doesn’t get populated in a destroyed component. That simulates a case where the user decides to navigate away from the current page, and while the new page intent is getting processed by the routing logic, the article response arrives. In that case, we don’t want to show the article information for a split second and then close it because it might cause a flash of content issue.

- We provide a good response by the articleAPI.get.
- We call `afterComponentInitialize` and store its result, the `initPromise`, in a constant and don’t `await` it. That allows us to destroy the component before the response arrives, simulating the second part of the condition above.
- We call beforeComponentDestroy to simulate the first part of the condition above.
- We use `await initPromise`, simulating the response arriving.
- We assert that the `article` property is indeed `undefined` as expected.


**Test case 6**


```js
it(`when destroyed it should not inform user upon article fetch failed`, async () => {
  // arrange
  component.articleId = 1;
  articleAPI.get.and.returnValue(Promise.reject('error'));
  const initPromise = component.afterComponentInitialize();
  // act
  component.beforeComponentDestroy();
  await initPromise;
  // assert
  expect(userMessenger.error).not.toHaveBeenCalledOnceWith('Could not fetch article id: "1". Please try again.');
});
```

The above test case ensures that the user is not notified of an error after they’ve decided to navigate away from this component (for example, if the response took too long and timed out):

- We provide a rejected `Promise` to the `articleAPI.get`, simulating the timed-out response.
- We invoke `afterComponentInitialize` and store its result (the `Promise`) in the `initPromise` response to `await` it later.
- We invoke `beforeComponentDestroy` to simulate the user navigating away and the framework destroying the component.
- We use await `initPromise` to simulate the server response arrival.
- We assert the the `error` method was not called.


# Exercise

For this lesson’s exercise, a delete article process with confirmation is added to the ArticleComponent in the form of three methods (see the code playground below). That implements a requirement to get the user’s confirmation before actually deleting an article. The process steps look like this:

1. The user clicks the “Delete” button on the article.
2. A dialog appears with a disclaimer that says, “Are you sure you want to delete the article …?” and two buttons: “Confirm” and “Cancel.”
3. The user either confirms and deletes the article, or cancels and backs out.


Find and finish the tests in `spec/article-component.spec.mjs` in the code playground below. They’re in a nested describe (`fdescribe`) test suite. Nesting `describe` in `describe` allows for some logical grouping of tests. The nested `describe` is an `fdescribe` that tells Jasmine to focus on this `describe` and only perform its tests. This is so that the rest of the tests don’t clutter the exercise ones. Feel free to leave it as is or replace it with a `describe` at any time.


There are a few tests for this exercise:

- When `onDeleteArticle` is invoked, the dialog `showDeleteArticleConfirmationDialog === true` should be shown.
- When `onDeleteArticle` gets invoked, and then `onDeleteArticleCancel` is invoked, a call to the `delete` method on the API does NOT happen. And the dialog `showDeleteArticleConfirmationDialog` should be hidden.

- When `onDeleteArticle` and then `onDeleteArticleConfirm` get invoked, a call to the delete method on the API happens. The info method on the `userMessenger` should also be called with a specific message.


If stuck, see the hints below.

Understand the specifics of a single-page application component and its testing, such as lifecycle hooks and event handlers.

Overview

Testing JavaScript with Jasmine

Testing Asynchronous Code

Debugging Jasmine Tests

Summary

Test Single-page Application Components