Jest, Angular & React Testing Library: Unit & Integration Tests

Mastering Unit & Integration Testing: Jest, Angular & React TL

The Unseen Foundation: Why Testing Is Paramount

In the fast-paced world of frontend development, building interactive and robust user interfaces with frameworks like Angular and React is standard practice. However, shipping code without a solid testing strategy is akin to building a skyscraper on sand. Bugs creep in, features break, and refactoring becomes a terrifying ordeal.

This deep-dive will equip you with the knowledge and practical examples to master unit and integration testing using the powerful combination of Jest as your test runner and Angular/React Testing Library for interacting with your components. We'll explore why these tools are indispensable, how to set them up, and most importantly, how to write tests that are maintainable, reliable, and truly reflect user behavior.

Understanding the Pillars: Unit vs. Integration Testing

Before diving into code, it's crucial to distinguish between the two primary levels of testing we'll focus on:

Unit Testing: This level focuses on testing individual, isolated units of code. A "unit" can be a single function, a class method, or a small component in isolation. The goal is to verify that each unit performs as expected, independent of other parts of the system.
- Characteristics: Fast execution, isolated, easy to debug.
- Focus: Internal logic, function outputs, component rendering without dependencies.
Integration Testing: This level verifies that different units or components interact correctly when combined. It checks the interfaces and interactions between modules, ensuring that they work together seamlessly to achieve a larger functionality.
- Characteristics: Slower than unit tests, covers multiple components/services, mimics user flows.
- Focus: Data flow between components, API calls, state management, user interactions across features.

While both are vital, they serve different purposes. A comprehensive testing suite needs a good balance of both to catch various types of defects effectively.

The Core Tooling: Jest and Testing Library

Jest is a delightful JavaScript testing framework maintained by Facebook, renowned for its simplicity, speed, and comprehensive features. It's often the default choice for React projects but works excellently with Angular and other frameworks too.

Testing Library (specifically @testing-library/react and @testing-library/angular) is a set of utilities that helps you test UI components in a way that resembles how users interact with your application. Its guiding principle is: "The more your tests resemble the way your software is used, the more confidence they can give you."

This philosophy leads to more robust tests that break less often with refactors, as they focus on the component's public API and user-facing behavior rather than its internal implementation details.

Setting Up Jest for Angular/React Projects

If you're using create-react-app or Angular CLI, Jest and a basic setup for Testing Library are often included by default. However, let's look at a manual setup for clarity.

First, install Jest and the appropriate Testing Library package:

bash

npm install --save-dev jest @testing-library/react @testing-library/jest-dom @babel/preset-env @babel/preset-react
# Or for Angular:
npm install --save-dev jest @testing-library/angular @testing-library/jest-dom jest-preset-angular

Then, configure Jest. For React, you'll typically need Babel for JSX support. For Angular, jest-preset-angular simplifies configuration significantly.

jest.config.js

javascript

// jest.config.js for React
module.exports = {
  testEnvironment: 'jsdom',
  setupFilesAfterEnv: ['@testing-library/jest-dom/extend-expect'],
  moduleNameMapper: {
    '\\.(css|less|sass|scss)$': 'identity-obj-proxy',
  },
  transform: {
    '^.+\\.(js|jsx|ts|tsx)$': 'babel-jest',
  },
};

jest.config.js

javascript

// jest.config.js for Angular
module.exports = {
  preset: 'jest-preset-angular',
  setupFilesAfterEnv: ['<rootDir>/setup-jest.ts'],
  testEnvironment: 'jsdom',
  globals: {
    'ts-jest': {
      tsconfig: '<rootDir>/tsconfig.spec.json',
      stringifyContentPathRegex: '\\.(html|svg)$',
    },
  },
  displayName: 'Angular App Tests',
  transform: {
    '^.+\\.(ts|js|html)$': 'jest-preset-angular',
  },
  moduleNameMapper: {
    '^@app/(.*)$': '<rootDir>/src/app/$1',
  },
};

Jest-DOM for Matchers

`@testing-library/jest-dom` provides custom Jest matchers for asserting on the state of the DOM. For example, `toBeInTheDocument()` or `toBeDisabled()`. Always include it in `setupFilesAfterEnv` for a better testing experience.

Unit Testing Components with React Testing Library

React Testing Library encourages querying the DOM in the same way a user would find elements. This means preferring methods like getByText, getByLabelText, getByRole, or getByTestId over querySelector or component instance methods. Let's test a simple button component.

src/components/Button.tsx

typescript

// src/components/Button.tsx
import React from 'react';

interface ButtonProps {
  onClick: () => void;
  children: React.ReactNode;
  isDisabled?: boolean;
}

const Button: React.FC<ButtonProps> = ({ onClick, children, isDisabled = false }) => {
  return (
    <button onClick={onClick} disabled={isDisabled} data-testid="custom-button">
      {children}
    </button>
  );
};

export default Button;

src/components/Button.test.tsx

typescript

// src/components/Button.test.tsx
import React from 'react';
import { render, screen, fireEvent } from '@testing-library/react';
import Button from './Button';

describe('Button', () => {
  test('renders with children and responds to click', () => {
    const handleClick = jest.fn();
    render(<Button onClick={handleClick}>Click Me</Button>);
    const buttonElement = screen.getByText(/Click Me/i);
    expect(buttonElement).toBeInTheDocument();
    fireEvent.click(buttonElement);
    expect(handleClick).toHaveBeenCalledTimes(1);
  });

  test('is disabled when isDisabled prop is true', () => {
    const handleClick = jest.fn();
    render(<Button onClick={handleClick} isDisabled>Disabled Button</Button>);
    const buttonElement = screen.getByRole('button', { name: /Disabled Button/i });
    expect(buttonElement).toBeDisabled();
    fireEvent.click(buttonElement);
    expect(handleClick).not.toHaveBeenCalled();
  });

  test('renders correctly via test ID', () => {
    render(<Button onClick={() => {}}>Test ID Button</Button>);
    const buttonElement = screen.getByTestId('custom-button');
    expect(buttonElement).toBeInTheDocument();
  });
});

Prioritize User-Centric Queries

Always try to find elements using the methods a user would, in this order of preference: `getByRole`, `getByLabelText`, `getByPlaceholderText`, `getByText`, `getByDisplayValue`, `getByAltText`, `getByTitle`, and finally `getByTestId`. Avoid querying by class names or component internal state where possible.

Unit Testing Components with Angular Testing Library

Angular Testing Library integrates seamlessly with Angular's TestBed but simplifies the query process significantly, aligning with the same user-centric principles as its React counterpart. Let's test a simple Angular component.

src/app/shared/button/button.component.ts

typescript

// src/app/shared/button/button.component.ts
import { Component, Input, Output, EventEmitter } from '@angular/core';

@Component({
  selector: 'app-button',
  template: `
    <button (click)="onClick.emit()" [disabled]="isDisabled" data-testid="angular-button">
      {{ label }}
    </button>
  `,
  styles: []
})
export class ButtonComponent {
  @Input() label: string = 'Click Me';
  @Input() isDisabled: boolean = false;
  @Output() onClick = new EventEmitter<void>();

  constructor() { }
}

src/app/shared/button/button.component.spec.ts

typescript

// src/app/shared/button/button.component.spec.ts
import { render, screen, fireEvent } from '@testing-library/angular';
import { ButtonComponent } from './button.component';

describe('ButtonComponent', () => {
  test('should render with label and emit click event', async () => {
    const mockClick = jest.fn();
    await render(ButtonComponent, {
      componentProperties: { label: 'Submit', onClick: mockClick }
    });
    const buttonElement = screen.getByText(/Submit/i);
    expect(buttonElement).toBeInTheDocument();
    fireEvent.click(buttonElement);
    expect(mockClick).toHaveBeenCalledTimes(1);
  });

  test('should be disabled when isDisabled is true', async () => {
    const mockClick = jest.fn();
    await render(ButtonComponent, {
      componentProperties: { label: 'Disabled', isDisabled: true, onClick: mockClick }
    });
    const buttonElement = screen.getByRole('button', { name: /Disabled/i });
    expect(buttonElement).toBeDisabled();
    fireEvent.click(buttonElement);
    expect(mockClick).not.toHaveBeenCalled();
  });

  test('should render correctly via test ID', async () => {
    await render(ButtonComponent, { componentProperties: { label: 'Test ID Button' } });
    const buttonElement = screen.getByTestId('angular-button');
    expect(buttonElement).toBeInTheDocument();
  });
});

Angular `async` in Tests

When using `render` from `@testing-library/angular`, it often returns a promise. Using `await` ensures that the component has rendered and settled before you start querying and asserting. This helps in correctly testing components that might have asynchronous initialization.

Stepping Up: Integration Testing

While unit tests confirm individual parts work, integration tests ensure these parts collaborate correctly. This is where you test a component that interacts with a service, a hook, or another component. We often mock dependencies at the boundaries of our integration to control the test environment and focus on the interaction within our system rather than external systems (like a real API).

React Integration Test: Component with a Custom Hook

Let's imagine a component that fetches data using a custom hook.

src/hooks/useFetchUsers.ts

typescript

// src/hooks/useFetchUsers.ts
import { useState, useEffect } from 'react';

interface User {
  id: number;
  name: string;
}

const useFetchUsers = (url: string) => {
  const [users, setUsers] = useState<User[]>([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    const fetchUsers = async () => {
      try {
        setLoading(true);
        const response = await fetch(url);
        if (!response.ok) {
          throw new Error(`HTTP error! status: ${response.status}`);
        }
        const data: User[] = await response.json();
        setUsers(data);
      } catch (err: any) {
        setError(err.message);
      } finally {
        setLoading(false);
      }
    };
    fetchUsers();
  }, [url]);

  return { users, loading, error };
};

export default useFetchUsers;

src/components/UserList.tsx

typescript

// src/components/UserList.tsx
import React from 'react';
import useFetchUsers from '../hooks/useFetchUsers';

const UserList: React.FC = () => {
  const { users, loading, error } = useFetchUsers('/api/users');

  if (loading) {
    return <div data-testid="loading">Loading users...</div>;
  }

  if (error) {
    return <div data-testid="error">Error: {error}</div>;
  }

  return (
    <ul data-testid="user-list">
      {users.map(user => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
};

export default UserList;

src/components/UserList.test.tsx

typescript

// src/components/UserList.test.tsx
import React from 'react';
import { render, screen, waitFor } from '@testing-library/react';
import UserList from './UserList';
import useFetchUsers from '../hooks/useFetchUsers';

// Mock the custom hook to control its return value
jest.mock('../hooks/useFetchUsers');

const mockedUseFetchUsers = useFetchUsers as jest.MockedFunction<typeof useFetchUsers>;

describe('UserList (Integration Test with mocked hook)', () => {
  test('displays loading state, then user data', async () => {
    mockedUseFetchUsers.mockReturnValue({
      users: [],
      loading: true,
      error: null,
    });

    render(<UserList />);
    expect(screen.getByTestId('loading')).toBeInTheDocument();

    // Simulate data fetching completion
    mockedUseFetchUsers.mockReturnValue({
      users: [{ id: 1, name: 'Alice' }, { id: 2, name: 'Bob' }],
      loading: false,
      error: null,
    });

    // Use waitFor to wait for the DOM to update after hook's state changes
    await waitFor(() => {
      expect(screen.queryByTestId('loading')).not.toBeInTheDocument();
      expect(screen.getByTestId('user-list')).toBeInTheDocument();
      expect(screen.getByText('Alice')).toBeInTheDocument();
      expect(screen.getByText('Bob')).toBeInTheDocument();
    });
  });

  test('displays error state when hook returns an error', async () => {
    mockedUseFetchUsers.mockReturnValue({
      users: [],
      loading: false,
      error: 'Failed to fetch users',
    });

    render(<UserList />);

    await waitFor(() => {
      expect(screen.getByTestId('error')).toHaveTextContent('Error: Failed to fetch users');
      expect(screen.queryByTestId('loading')).not.toBeInTheDocument();
      expect(screen.queryByTestId('user-list')).not.toBeInTheDocument();
    });
  });
});

Angular Integration Test: Component with a Service

Now, an Angular example where a component uses a service to fetch data.

src/app/services/user.service.ts

typescript

// src/app/services/user.service.ts
import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable, of } from 'rxjs';
import { delay } from 'rxjs/operators';

interface User {
  id: number;
  name: string;
}

@Injectable({ providedIn: 'root' })
export class UserService {
  constructor(private http: HttpClient) { }

  getUsers(): Observable<User[]> {
    // In a real app, this would be an actual HTTP call
    // return this.http.get<User[]>('/api/users');
    return of<User[]>([
      { id: 1, name: 'Charlie' },
      { id: 2, name: 'Diana' }
    ]).pipe(delay(100)); // Simulate network delay
  }
}

src/app/user-list/user-list.component.ts

typescript

// src/app/user-list/user-list.component.ts
import { Component, OnInit } from '@angular/core';
import { UserService } from '../services/user.service';
import { Observable, of } from 'rxjs';
import { catchError } from 'rxjs/operators';

interface User {
  id: number;
  name: string;
}

@Component({
  selector: 'app-user-list',
  template: `
    <div *ngIf="loading" data-testid="loading">Loading users...</div>
    <div *ngIf="error" data-testid="error">Error: {{ error }}</div>
    <ul *ngIf="users$ | async as users; else loading" data-testid="user-list">
      <li *ngFor="let user of users" [attr.data-testid]="'user-item-' + user.id">{{ user.name }}</li>
    </ul>
  `,
  styles: []
})
export class UserListComponent implements OnInit {
  users$!: Observable<User[]>;
  loading: boolean = true;
  error: string | null = null;

  constructor(private userService: UserService) { }

  ngOnInit(): void {
    this.users$ = this.userService.getUsers().pipe(
      catchError(err => {
        this.error = err.message || 'Unknown error';
        this.loading = false;
        return of([]);
      }),
      // Using tap to set loading to false after successful data fetch
      // Angular's async pipe implicitly handles subscription/unsubscription
      // For this example, setting loading here or in a 'finalize' operator is fine.
      // A more robust solution might involve distinct state for 'dataFetched' and 'loading'.
      tap(() => this.loading = false)
    );
  }
}

src/app/user-list/user-list.component.spec.ts

typescript

// src/app/user-list/user-list.component.spec.ts
import { render, screen, waitFor } from '@testing-library/angular';
import { UserListComponent } from './user-list.component';
import { UserService } from '../services/user.service';
import { of, throwError } from 'rxjs';
import { CommonModule } from '@angular/common'; // Required for *ngIf, *ngFor

describe('UserListComponent (Integration Test with mocked service)', () => {
  const mockUsers = [
    { id: 1, name: 'Frank' },
    { id: 2, name: 'Grace' }
  ];

  const mockUserService = {
    getUsers: jest.fn(() => of(mockUsers))
  };

  test('should display loading then list of users', async () => {
    await render(UserListComponent, {
      imports: [CommonModule], // Import CommonModule for directives
      providers: [
        { provide: UserService, useValue: mockUserService }
      ]
    });

    // Initial loading state
    expect(screen.getByTestId('loading')).toBeInTheDocument();

    // Wait for data to resolve and UI to update
    await waitFor(() => {
      expect(screen.queryByTestId('loading')).not.toBeInTheDocument();
      expect(screen.getByTestId('user-list')).toBeInTheDocument();
      expect(screen.getByTestId('user-item-1')).toHaveTextContent('Frank');
      expect(screen.getByTestId('user-item-2')).toHaveTextContent('Grace');
    });
    expect(mockUserService.getUsers).toHaveBeenCalledTimes(1);
  });

  test('should display error message on service error', async () => {
    mockUserService.getUsers.mockReturnValue(throwError(() => new Error('API down')));

    await render(UserListComponent, {
      imports: [CommonModule],
      providers: [
        { provide: UserService, useValue: mockUserService }
      ]
    });

    await waitFor(() => {
      expect(screen.getByTestId('error')).toHaveTextContent('Error: API down');
      expect(screen.queryByTestId('loading')).not.toBeInTheDocument();
      expect(screen.queryByTestId('user-list')).not.toBeInTheDocument();
    });
  });
});

Mocking Strategies

For integration tests, judicious mocking is key. Mock external dependencies (like HTTP requests or global APIs) to ensure your tests are fast, deterministic, and focus only on the interaction *within* your application's boundaries. Mocking too much makes tests fragile; mocking too little makes them slow and flaky.

Advanced Jest Features: Mocks, Spies, and Snapshots

Jest offers powerful features to handle complex testing scenarios.

Mock Functions (`jest.fn()`)

These allow you to test links between code by erasing the actual implementation of a function, capturing calls to it (and the parameters passed in those calls), controlling return values, and changing their implementation. They are incredibly useful for verifying callbacks or service method invocations.

Spies (`jest.spyOn()`)

A spy is similar to a mock function, but it doesn't replace the original implementation. Instead, it observes calls to an existing function without altering its behavior, unless you explicitly tell it to. This is great for asserting that a certain method was called on a real object.

Snapshot Testing (`.toMatchSnapshot()`)

Snapshot tests record the rendered output of a component or the serialized value of an object and compare it against a previously stored snapshot file. If the new snapshot doesn't match the stored one, the test fails. This is useful for UI components to ensure unintentional changes don't occur. Always review snapshot changes carefully!

src/utils/api.test.ts

typescript

// Example demonstrating jest.fn() and jest.spyOn()
class APIClient {
  fetchData(id: string) {
    return Promise.resolve({ id, data: `Data for ${id}` });
  }
  postData(payload: any) {
    return Promise.resolve({ success: true, payload });
  }
}

describe('APIClient with Mocks and Spies', () => {
  let client: APIClient;

  beforeEach(() => {
    client = new APIClient();
  });

  test('should call fetchData and return mocked data', async () => {
    const mockFetch = jest.fn(() => Promise.resolve({ id: 'mocked', data: 'Mocked Data' }));
    client.fetchData = mockFetch; // Replace actual method with mock

    const result = await client.fetchData('123');
    expect(mockFetch).toHaveBeenCalledWith('123');
    expect(result).toEqual({ id: 'mocked', data: 'Mocked Data' });
  });

  test('should spy on postData without changing its behavior', async () => {
    const spy = jest.spyOn(client, 'postData');
    const payload = { key: 'value' };

    const result = await client.postData(payload);

    expect(spy).toHaveBeenCalledWith(payload);
    expect(result).toEqual({ success: true, payload }); // Original implementation runs
    spy.mockRestore(); // Important to restore original implementation after test
  });
});

Testing Asynchronous Code Effectively

Modern frontend applications are inherently asynchronous. Fetching data, animations, and user interactions often involve promises, timeouts, or callbacks. Jest and Testing Library provide robust ways to handle this.

async/await: The most common and readable way to test promise-based asynchronous code.
waitFor: From Testing Library, waitFor allows you to wait for an assertion to pass. It repeatedly executes a callback function until it no longer throws an error or the timeout is reached. This is crucial for UI updates that happen after an async operation completes.
findBy* queries: Testing Library queries like findByText, findByRole, etc., are asynchronous variants of getBy* queries. They return a promise that resolves when an element is found (or rejects if not found within a timeout), making them perfect for elements that appear on the screen after some asynchronous operation.

Conclusion: Building Confidence Through Comprehensive Testing

By diligently implementing unit and integration tests using Jest and Angular/React Testing Library, you're not just finding bugs; you're building a safety net that allows for confident refactoring, faster feature development, and a more stable application in the long run. Remember the core principles:

Test one thing at a time: Keep unit tests focused and isolated.
Test user behavior: Use Testing Library to interact with your components like a real user.
Balance unit and integration tests: Cover both granular logic and the crucial interactions between components.
Mock intelligently: Control external dependencies to make tests fast and reliable.

Embrace testing as an integral part of your development workflow, and you'll find yourself shipping higher quality code with greater peace of mind. Happy testing!

Enjoyed this deep dive?

Tags:JestReact Testing LibraryAngular Testing LibraryUnit TestingIntegration TestingFrontend Testing

Discussion & Feedback

0 thoughts shared by the community

Loading discussion thread...

Back to All Articles

Mastering Unit & Integration Testing: Jest, Angular & React TL

Jest-DOM for Matchers

Prioritize User-Centric Queries

Angular `async` in Tests

Mocking Strategies

Discussion & Feedback