In this tutorial, you’ll learn how to set up Vitest in a React project, write effective tests for your components and hooks, and understand the testing patterns that will help you build more reliable applications.

Table of Contents

• What is Vitest and Why Should You Use It?

• Prerequisites

• How to Set Up Vitest in Your React Project

• How to Write Your First Test

• How to Test React Components

• How to Test User Interactions

• How to Test Custom Hooks

• How to Mock API Calls

• Best Practices for Testing React Components

What is Vitest and Why Should You Use It?

Vitest is a testing framework built on top of Vite. It uses Vite’s development server and plugin pipeline to transform and load files during testing. This means your tests use the same configuration and plugins as your app (for example, the React plugin, TypeScript support,and so on), so you don’t need a separate build or compile step.

Vitest runs tests in parallel across worker threads for maximum speed, and it automatically enables an instant “watch” mode (similar to Vite’s HMR) that reruns only the tests related to changed files. Vitest also has first-class support for modern JavaScript out of the box: it handles ESM, TypeScript, and JSX natively via Vite’s transformer (powered by Oxc).

Because Vitest provides a Jest-compatible API, you can continue to use familiar testing libraries (for example, React Testing Library, jest-dom matchers, user-event, and so on) without extra setup.

In short, Vitest tightly integrates with your Vite-powered stack (or can even run standalone) and lets you plug in existing testing tools seamlessly.

Here is why Vitest has become popular in the React ecosystem:

• Speed: Vitest can run tests more than four times faster than Jest in many scenarios. This speed comes from Vite's fast Hot Module Replacement and efficient caching capabilities.

• Zero configuration: Unlike Jest, which required Babel integration, TSJest setup, and multiple dependencies, Vitest works out of the box. It reuses your existing Vite configuration, eliminating the need to configure a separate test pipeline.

• Native TypeScript support: Vitest handles TypeScript and JSX natively through ESBuild, with no additional configuration needed.

• Modern JavaScript: Vitest offers native support for ES modules out of the box, making it ideal for modern JavaScript stacks.

• Familiar API: If you know Jest, you already know most of Vitest. The API is intentionally compatible, making migration straightforward.

Prerequisites

To follow along with this tutorial, you should have:

• Basic knowledge of React and JavaScript

• Understanding of React Hooks

• Node.js installed (version 14 or higher)

• A React project created with Vite (or you can create one as we go)

How to Set Up Vitest in Your React Project

Let's start by creating a new React project with Vite and setting up Vitest.

Step 1: Create a React Project with Vite

If you don't have an existing project, create one with the following command:

npm create vite@latest my-react-app -- --template react
cd my-react-app
npm install

This creates a React project with Vite as the build tool.

Step 2: Install Vitest and Testing Dependencies

Install Vitest along with the React Testing Library and other necessary dependencies:

npm install --save-dev vitest @testing-library/react @testing-library/jest-dom @testing-library/user-event jsdom

Here's what each package does:

• vitest: The testing framework itself

• @testing-library/react: Provides utilities for testing React components

• @testing-library/jest-dom: Adds custom matchers for DOM assertions

• @testing-library/user-event: Simulates user interactions

• jsdom: Provides a DOM environment for testing

Step 3: Configure Vitest

Create a vitest.config.js file in your project root:

import { defineConfig } from 'vitest/config';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
  test: {
    globals: true,
    environment: 'jsdom',
    setupFiles: './src/test/setup.js',
  },
});

Setting globals: true exposes the describe and it functions on the global object, so you don't need to import them in every test file. The environment: 'jsdom' setting tells Vitest to use jsdom for simulating a browser environment.

Step 4: Create the Test Setup File

Create a file at src/test/setup.js:

import { expect, afterEach } from 'vitest';
import { cleanup } from '@testing-library/react';
import '@testing-library/jest-dom';

afterEach(() => {
  cleanup();
});

The cleanup() function runs after each test to clean up the DOM, ensuring tests don't interfere with each other.

Step 5: Add Test Scripts

Add the following script to your package.json:

{
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "test": "vitest",
    "test:ui": "vitest --ui",
    "coverage": "vitest --coverage"
  }
}

Now you can run tests with npm test.

How to Write Your First Test

Let's write a simple test to make sure everything is working. Create a file called sum.test.js in your src directory:

import { expect, test } from 'vitest';

function sum(a, b) {
  return a + b;
}

test('adds 1 + 2 to equal 3', () => {
  expect(sum(1, 2)).toBe(3);
});

Run npm test and you should see your test pass. A test in Vitest passes if it doesn't throw an error.

How to Test React Components

Now let's test an actual React component. We'll start with a simple component and gradually build up to more complex scenarios.

Testing a Simple Component

Create a component called Greeting.jsx:

export function Greeting({ name }) {
  return (
    <div>
      <h1>Hello, {name}!</h1>
      <p>Welcome to our application</p>
    </div>
  );
}

Now create a test file Greeting.test.jsx:

import { render, screen } from '@testing-library/react';
import { Greeting } from './Greeting';

describe('Greeting Component', () => {
  it('should render the greeting with the provided name', () => {
    render(<Greeting name="Alice" />);

    const heading = screen.getByRole('heading', { level: 1 });
    expect(heading).toHaveTextContent('Hello, Alice!');
  });

  it('should render the welcome message', () => {
    render(<Greeting name="Bob" />);

    const paragraph = screen.getByText('Welcome to our application');
    expect(paragraph).toBeInTheDocument();
  });
});

The describe function groups related tests into a single describe block. Each it function contains one test case.

The render function from React Testing Library renders your component in a test environment. The screen object provides query methods to find elements in the rendered output.

Understanding Query Functions

React Testing Library provides three types of query functions: get, query, and find.

getBy queries: Throw an error if the element isn't found. Use these when you expect the element to be present.

const button = screen.getByRole('button', { name: /click me/i });

queryBy queries: Return null if the element isn't found. Use these when you want to assert that an element doesn't exist.

const errorMessage = screen.queryByText('Error');
expect(errorMessage).not.toBeInTheDocument();

findBy queries: Return a promise and wait for the element to appear. Use these for asynchronous operations.

const loadedData = await screen.findByText('Data loaded');

Testing a Counter Component

Let's test a more interactive component. Create Counter.jsx:

import { useState } from 'react';

export function Counter({ initialCount = 0 }) {
  const [count, setCount] = useState(initialCount);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>
      <button onClick={() => setCount(count - 1)}>Decrement</button>
      <button onClick={() => setCount(0)}>Reset</button>
    </div>
  );
}

Create the test file Counter.test.jsx:

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { Counter } from './Counter';

describe('Counter Component', () => {
  it('should render with initial count of 0', () => {
    render(<Counter />);

    expect(screen.getByText('Count: 0')).toBeInTheDocument();
  });

  it('should render with custom initial count', () => {
    render(<Counter initialCount={5} />);

    expect(screen.getByText('Count: 5')).toBeInTheDocument();
  });

  it('should increment count when increment button is clicked', async () => {
    const user = userEvent.setup();
    render(<Counter />);

    const incrementButton = screen.getByRole('button', { name: /increment/i });
    await user.click(incrementButton);

    expect(screen.getByText('Count: 1')).toBeInTheDocument();
  });

  it('should decrement count when decrement button is clicked', async () => {
    const user = userEvent.setup();
    render(<Counter initialCount={5} />);

    const decrementButton = screen.getByRole('button', { name: /decrement/i });
    await user.click(decrementButton);

    expect(screen.getByText('Count: 4')).toBeInTheDocument();
  });

  it('should reset count to 0 when reset button is clicked', async () => {
    const user = userEvent.setup();
    render(<Counter initialCount={10} />);

    const resetButton = screen.getByRole('button', { name: /reset/i });
    await user.click(resetButton);

    expect(screen.getByText('Count: 0')).toBeInTheDocument();
  });
});

In these Counter tests, we first use render(<Counter />) to mount the component in a virtual DOM. We then query the output using Testing Library’s screen object. For example, screen.getByText('Count: 0') finds the element displaying the initial count of 0, and expect(...).toBeInTheDocument() asserts that it is present. The getByText query will throw an error if the text isn’t found, immediately failing the test.

For interactive tests, we create a user with const user = userEvent.setup() and then call await user.click(...) on the increment/decrement/reset buttons. The userEvent.click method simulates a real user click (dispatching the sequence of events a browser would fire). We locate buttons by their accessible role and name (for example, getByRole('button', { name: /increment/i })), following best practices for accessible queries.

After each click, we assert that the DOM updates accordingly (for example, the count text changes to “Count: 1”). Using async/await with user.click ensures the test waits for any state changes. In this way, each test checks the user-visible behavior: that clicking the Increment button increases the count, the Decrement button decreases it, and the Reset button sets it back to zero, without depending on the component’s internal implementation.

How to Test User Interactions

User interactions are a critical part of testing React applications. The @testing-library/user-event library provides a more realistic simulation of user behaviour than simple event dispatching.

Testing Form Inputs

Create a LoginForm.jsx component:

import { useState } from 'react';

export function LoginForm({ onSubmit }) {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const [error, setError] = useState('');

  const handleSubmit = (e) => {
    e.preventDefault();

    if (!email || !password) {
      setError('Both fields are required');
      return;
    }

    setError('');
    onSubmit({ email, password });
  };

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <label htmlFor="email">Email</label>
        <input
          id="email"
          type="email"
          value={email}
          onChange={(e) => setEmail(e.target.value)}
        />
      </div>
      <div>
        <label htmlFor="password">Password</label>
        <input
          id="password"
          type="password"
          value={password}
          onChange={(e) => setPassword(e.target.value)}
        />
      </div>
      {error && <p role="alert">{error}</p>}
      <button type="submit">Log In</button>
    </form>
  );
}

Create the test file LoginForm.test.jsx:

import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { LoginForm } from './LoginForm';

describe('LoginForm Component', () => {
  it('should render email and password inputs', () => {
    render(<LoginForm onSubmit={() => {}} />);

    expect(screen.getByLabelText(/email/i)).toBeInTheDocument();
    expect(screen.getByLabelText(/password/i)).toBeInTheDocument();
  });

  it('should update input values when user types', async () => {
    const user = userEvent.setup();
    render(<LoginForm onSubmit={() => {}} />);

    const emailInput = screen.getByLabelText(/email/i);
    const passwordInput = screen.getByLabelText(/password/i);

    await user.type(emailInput, 'test@example.com');
    await user.type(passwordInput, 'password123');

    expect(emailInput).toHaveValue('test@example.com');
    expect(passwordInput).toHaveValue('password123');
  });

  it('should show error when form is submitted empty', async () => {
    const user = userEvent.setup();
    const mockSubmit = vi.fn();
    render(<LoginForm onSubmit={mockSubmit} />);

    const submitButton = screen.getByRole('button', { name: /log in/i });
    await user.click(submitButton);

    expect(screen.getByRole('alert')).toHaveTextContent('Both fields are required');
    expect(mockSubmit).not.toHaveBeenCalled();
  });

  it('should call onSubmit with form data when valid', async () => {
    const user = userEvent.setup();
    const mockSubmit = vi.fn();
    render(<LoginForm onSubmit={mockSubmit} />);

    await user.type(screen.getByLabelText(/email/i), 'test@example.com');
    await user.type(screen.getByLabelText(/password/i), 'password123');
    await user.click(screen.getByRole('button', { name: /log in/i }));

    expect(mockSubmit).toHaveBeenCalledWith({
      email: 'test@example.com',
      password: 'password123',
    });
  });
});

The LoginForm tests similarly use render and screen to interact with the component. We use screen.getByLabelText(/email/i) and screen.getByLabelText(/password/i) to find the input fields by their associated labels, mimicking how users identify form fields.

To simulate typing, we use await user.type(input, text), which sends real keyboard events to the input (via user-event). After typing, we assert the input’s value with expect(input).toHaveValue(...) (a custom matcher from jest-dom).

When submitting the form empty, clicking the Log In button triggers the form’s validation and displays an error message. We find this error by querying getByRole('alert') and check its text content. We also assert that the mock onSubmit handler was not called.

In the valid submission test, we fill both fields and click Log In; then expect(mockSubmit).toHaveBeenCalledWith({...}) verifies the submit handler received the correct { email, password } object.

These tests focus on user actions and outcomes: typing and clicking drive the form logic, and our assertions confirm the expected outputs (visible error text or the callback arguments).

How to Test Custom Hooks

Custom hooks encapsulate reusable logic, and they need testing just like components. React Testing Library provides a renderHook function specifically for this purpose.

Creating and Testing a Custom Hook

Create a custom hook useFetch.js:

import { useState, useEffect } from 'react';

export function useFetch(url) {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchData = async () => {
      try {
        setLoading(true);
        const response = await fetch(url);

        if (!response.ok) {
          throw new Error('Network response was not ok');
        }

        const json = await response.json();
        setData(json);
        setError(null);
      } catch (err) {
        setError(err.message);
        setData(null);
      } finally {
        setLoading(false);
      }
    };

    fetchData();
  }, [url]);

  return { data, loading, error };
}

Create the test file useFetch.test.js:

import { renderHook, waitFor } from '@testing-library/react';
import { useFetch } from './useFetch';

describe('useFetch Hook', () => {
  beforeEach(() => {
    global.fetch = vi.fn();
  });

  afterEach(() => {
    vi.restoreAllMocks();
  });

  it('should return loading state initially', () => {
    global.fetch.mockImplementation(() => 
      Promise.resolve({
        ok: true,
        json: async () => ({ data: 'test' }),
      })
    );

    const { result } = renderHook(() => useFetch('https://api.example.com/data'));

    expect(result.current.loading).toBe(true);
    expect(result.current.data).toBe(null);
    expect(result.current.error).toBe(null);
  });

  it('should return data when fetch succeeds', async () => {
    const mockData = { id: 1, title: 'Test Post' };

    global.fetch.mockImplementation(() =>
      Promise.resolve({
        ok: true,
        json: async () => mockData,
      })
    );

    const { result } = renderHook(() => useFetch('https://api.example.com/posts/1'));

    await waitFor(() => expect(result.current.loading).toBe(false));

    expect(result.current.data).toEqual(mockData);
    expect(result.current.error).toBe(null);
  });

  it('should return error when fetch fails', async () => {
    global.fetch.mockImplementation(() =>
      Promise.resolve({
        ok: false,
      })
    );

    const { result } = renderHook(() => useFetch('https://api.example.com/posts/1'));

    await waitFor(() => expect(result.current.loading).toBe(false));

    expect(result.current.data).toBe(null);
    expect(result.current.error).toBe('Network response was not ok');
  });
});

The renderHook function from React Testing Library renders custom hooks, and waitFor is used to wait for asynchronous state updates in the hook.

How to Mock API Calls

When testing components that make API calls, you don't want to hit real endpoints. Mocking ensures your tests are fast, reliable, and don't depend on network conditions.

Mocking with Vitest

Vitest doesn’t auto-mock modules like Jest does, so you need to manually mock them. Let's see how to mock an Axios call.

Create a PostsList.jsx component:

import { useState, useEffect } from 'react';
import axios from 'axios';

export function PostsList() {
  const [posts, setPosts] = useState([]);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchPosts = async () => {
      try {
        const response = await axios.get('https://api.example.com/posts');
        setPosts(response.data);
      } catch (err) {
        setError(err.message);
      } finally {
        setLoading(false);
      }
    };

    fetchPosts();
  }, []);

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error}</p>;

  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  );
}

Create the test file PostsList.test.jsx:

import { render, screen, waitFor } from '@testing-library/react';
import axios from 'axios';
import { PostsList } from './PostsList';

vi.mock('axios');

describe('PostsList Component', () => {
  beforeEach(() => {
    vi.clearAllMocks();
  });

  it('should display loading state initially', () => {
    axios.get.mockImplementation(() => new Promise(() => {}));
    render(<PostsList />);

    expect(screen.getByText('Loading...')).toBeInTheDocument();
  });

  it('should display posts when API call succeeds', async () => {
    const mockPosts = [
      { id: 1, title: 'First Post' },
      { id: 2, title: 'Second Post' },
    ];

    axios.get.mockResolvedValue({ data: mockPosts });
    render(<PostsList />);

    await waitFor(() => {
      expect(screen.queryByText('Loading...')).not.toBeInTheDocument();
    });

    expect(screen.getByText('First Post')).toBeInTheDocument();
    expect(screen.getByText('Second Post')).toBeInTheDocument();
  });

  it('should display error when API call fails', async () => {
    axios.get.mockRejectedValue(new Error('Network error'));
    render(<PostsList />);

    await waitFor(() => {
      expect(screen.queryByText('Loading...')).not.toBeInTheDocument();
    });

    expect(screen.getByText(/error/i)).toBeInTheDocument();
  });
});

In these tests, we verify specific UI states: the “loading” test checks that a loading indicator shows while data is being fetched, the “success” test confirms that post items render when the API returns data, and the “error” test makes sure an error message appears if the call fails.

We mock Axios by calling vi.mock('axios') and then using methods like mockResolvedValue(...) on axios.get to simulate a successful response (and mockRejectedValue(...) to simulate a failure). This kind of mocking isolates our tests from real network calls (making them fast and reliable) and lets us control exactly what data or error the hook receives.

We use await waitFor(...) to pause the test until those asynchronous updates complete before making assertions. Finally, we use screen.getByText(...) to find elements that should be present (it will throw an error if they’re missing) and screen.queryByText(...) to check that elements aren’t present (it returns null if the element is not in the DOM).

Mocking Specific Module Functions

Sometimes you only want to mock specific functions while keeping the rest of a module's behaviour intact. Here's how to do that:

vi.mock('date-fns', async () => {
  const original = await vi.importActual('date-fns');
  return {
    ...original,
    format: vi.fn(() => '2025-01-01'),
  };
});

In Vitest, you use vi.importActual to retain all original methods while mocking only the format method.

Best Practices for Testing React Components

Now that you know how to write tests, let's talk about how to write good tests.

Test User Behaviour, Not Implementation

Focus on testing what users see and do, not internal component details. If you refactor your component's implementation without changing its behaviour, your tests shouldn't break.

Bad test (testing implementation):

it('should set isOpen state to true', () => {
  const { result } = renderHook(() => useState(false));
  // Testing internal state directly
});

Good test (testing behaviour):

it('should show menu when button is clicked', async () => {
  const user = userEvent.setup();
  render(<Menu />);

  await user.click(screen.getByRole('button', { name: /menu/i }));
  expect(screen.getByRole('navigation')).toBeVisible();
});

Use Accessible Queries

React Testing Library encourages you to query elements the way users do. Prefer queries that mirror user interaction:

1. getByRole (best for interactive elements)

2. getByLabelText (for form fields)

3. getByPlaceholderText

4. getByText

5. getByTestId (last resort)

Keep Tests Simple and Focused

Each test should verify one thing. If your test needs a lot of setup or has many assertions, consider splitting it into multiple tests.

Clean Up Between Tests

Use afterEach to clean up the DOM after each test run, ensuring tests don't interfere with each other. This is already handled if you followed the setup steps earlier.

Use Descriptive Test Names

Test names should clearly describe what they're testing and what the expected outcome is.

Good test names:

it('should display error message when form is submitted empty');
it('should call onSubmit with email and password when form is valid');
it('should disable submit button while request is pending');

Mock External Dependencies

Always mock API calls, timers, and other external dependencies. Your tests should be isolated and not depend on network conditions or external services.

Conclusion

Now, you have learned how to set up Vitest in a React project and write effective tests for components, user interactions, custom hooks, and API calls. Vitest provides a powerful and efficient way to test React applications, especially when combined with modern tools like Vite.

Testing is about building confidence in your code, documenting expected behaviour, and enabling safe refactoring. Vitest's speed makes testing feel less like a chore and more like a natural part of development.

Start small. Add tests for critical user flows. Test the components that change frequently. As you build the habit, you will find that tests actually make development faster, not slower. The code will still be there tomorrow. But the bugs you catch today won't be.

Go takes a deliberately minimal approach to testing. There are no built-in assertions, no annotations, and no special syntax. Instead, tests are written as regular Go code using a small standard library package, and run with a single command. This can feel unusual at first if you're coming from ecosystems with richer testing frameworks, but it quickly becomes predictable and easy to reason about.

In this article, we'll look at how unit testing works in Go in practice. We'll write a few small tests, run them from the command line, and cover the most common patterns you'll see in real Go codebases, such as table-driven tests and testing functions that return errors. We'll focus on the essentials and won't cover more advanced topics like mocks or external frameworks.

The goal is to show how familiar testing concepts translate into idiomatic Go. By the end, you should feel comfortable reading and writing basic unit tests and integrating them into your regular Go workflow.

What We'll Cover:

1. Prerequisites

2. Writing Your First Test

   • Running Your Test

   • Divide by Zero

   • t.Errorf vs t.Fatalf

3. Table-Driven Tests

   • Table-Driven Add Test

   • Table-Driven Divide Test

   • Exercise

4. Testing Functions That Return Errors

   • Safe Divide Function

   • Writing Tests for SafeDivide()

   • Exercise

5. Best Practices and Tips

   • Name Tests Clearly

   • Keep Tests Small and Focused

   • Use Table-Driven Tests for Repetitive Cases

   • Check Errors Explicitly

   • Avoid Panics When Possible

   • Run Tests Frequently

   • Keep Tests in the Same Package

   • Use t.Fatalf vs t.Errorf Appropriately

6. Conclusion

7. Solutions to Exercises

   • Subtract Function and Tests

   • SafeSubtract Function and Tests

Prerequisites

Before you start, you should be comfortable with:

• Writing and running basic Go programs

• Defining and calling functions in Go

• Understanding basic Go types (int, string, bool, and so on)

• Using the Go command-line tool (go run, go build)

• Basic understanding of unit tests: what a test is and why it's useful

• Familiarity with Test-Driven Development concepts like testing before or alongside writing code

• Awareness of common testing ideas such as assertions, test coverage, and checking error conditions

You don't need prior experience with Go's testing package or Go-specific test patterns, as this guide will cover all of that.

Writing Your First Test

Let's start with a simple function to test. Imagine you have a small calc package with an Add function:

// calc.go
package calc

// Add returns the sum of two integers
func Add(a, b int) int {
    return a + b
}

To test this function, create a new file named calc_test.go in the same package. In Go, test files must end with _test.go to be recognized by the testing tool.

Inside calc_test.go, you write a test function:

// calc_test.go
package calc

import "testing"

func TestAdd(t *testing.T) {
    got := Add(2, 3)
    want := 5
    if got != want {
        t.Errorf("Add(2, 3) = %d; want %d", got, want)
    }
}

Here's what's happening:

• The function name starts with Test and takes a single *testing.T parameter. Go automatically discovers and runs any function that follows this convention.

• The t.Errorf call reports a test failure. Unlike some frameworks, Go doesn't provide special assertions – you simply check a condition and call t.Errorf or t.Fatalf if it fails.

• Each test is a standalone function. You can write as many as you like, and Go will run them all.

Running Your Test

Once the file is saved, you can run your test with:

go test

This runs tests for the current package (files ending with _test.go). If you want to run tests recursively in all subdirectories of your project, use:

go test ./...

The ./... pattern is shorthand for "run tests in this directory and all subdirectories". This is especially useful in larger projects where your code is spread across multiple packages.

If everything is working, you should see output indicating that the test passed:

$ go test
PASS
ok      _/C_/projects/Articles/Go_Testing       0.334s

You can add the -v flag for verbose output:

go test -v

This will show you the names of the tests as they run:

$ go test -v
=== RUN   TestAdd
--- PASS: TestAdd (0.00s)
PASS
ok      _/C_/projects/Articles/Go_Testing       0.356s

Not much difference for a single test, but it becomes useful as you add more tests.

Now let's see what happens if the test fails. Change the expected value in calc_test.go to an incorrect one:

  ...
    want := 6 // Incorrect expected value
  ...

Run the tests again:

$ go test
--- FAIL: TestAdd (0.00s)
    calc_test.go:9: Add(2, 3) = 5; want 6
FAIL
exit status 1
FAIL    _/C_/projects/Articles/Go_Testing       0.340s

or with verbose output:

$ go test -v
=== RUN   TestAdd
    calc_test.go:9: Add(2, 3) = 5; want 6
--- FAIL: TestAdd (0.00s)
FAIL
exit status 1
FAIL    _/C_/projects/Articles/Go_Testing       0.337s

Of course, your tests should always check for the correct expected values! A failing (but correct) test is a sign that your code needs to be fixed.

We only created one test file and one test function with one assertion here, but Go's testing tool can handle many files and functions at once. Behind the scenes, Go will automatically:

• Find all _test.go files in the specified packages (for example, current directory for go test, or recursively in all subdirectories with go test ./...).

• Identify functions that start with Test and have the correct signature.

• Compile them together with your package into a temporary test binary.

• Execute each test function and report the results.

To prove this, let's quickly add a Divide function to our package:

// calc.go
...
// Divide returns the result of dividing a by b
func Divide(a, b int) int {
    return a / b
}

(Note that this is an integer division, so fractional parts are discarded. Divide(5, 2) would return 2.)

And another test file with a corresponding test:

// calc_2_test.go
package calc

import "testing"

func TestDivide(t *testing.T) {
    got := Divide(10, 2)
    want := 5    
    if got != want {
        t.Errorf("Divide(10, 2) = %d; want %d", got, want)
    }    
}

Now when you run go test, both TestAdd and TestDivide will be executed:

$ go test
PASS
ok      _/C_/projects/Articles/Go_Testing       0.325s

Or:

$ go test -v
=== RUN   TestAdd
--- PASS: TestAdd (0.00s)
=== RUN   TestDivide
--- PASS: TestDivide (0.00s)
PASS
ok      _/C_/projects/Articles/Go_Testing       0.323s

Divide by Zero

What happens if we try to Divide by zero? Let's add another test case for that:

// calc_test.go
...
func TestDivideByZero(t *testing.T) {
    defer func() {
        if r := recover(); r == nil { // Check if a panic occurred
            t.Errorf("Divide did not panic on division by zero")
        }
    }()
    Divide(10, 0) // This should cause a panic
}

This test checks that the Divide function panics when dividing by zero. When you run the tests again, you'll see that this new test also passes:

$ go test -v
=== RUN   TestAdd
--- PASS: TestAdd (0.00s)
=== RUN   TestDivide
--- PASS: TestDivide (0.00s)
=== RUN   TestDivideByZero
--- PASS: TestDivideByZero (0.00s)
PASS
ok      _/C_/projects/Articles/Go_Testing       0.312s

(Note that in real-world Go code, it's better to return (int, error) for unsafe operations instead of panicking.)

Feel free to experiment by adding more test cases, changing expected values, and exploring how Go's testing framework handles different scenarios.

t.Errorf vs t.Fatalf

In the examples above, we used t.Errorf to report test failures. This function logs the error but allows the test to continue running. This is useful when you want to check multiple conditions in a single test function.

In contrast, t.Fatalf logs the error and immediately stops the execution of the current test. Use t.Fatalf when continuing the test after a failure doesn't make sense or could cause misleading results.

For example, in the TestDivideByZero test, if the Divide function does not panic, we use t.Errorf to report the failure but continue to the end of the test. But if we had additional checks after the division, we might want to use t.Fatalf to stop execution immediately upon failure.

While t.Errorf and t.Fatalf use fmt-style formatting, for simple messages without formatting, you can also use t.Error and t.Fatal, respectively.

In the next section, we'll look at table-driven tests, a common Go pattern for testing multiple cases efficiently.

Table-Driven Tests

In Go, it's common to want to run the same test logic for multiple inputs and expected outputs. Rather than writing a separate test function for each case, Go developers often use table-driven tests. This pattern keeps your tests concise, readable, and easy to extend.

Table-Driven Add Test

Let's rewrite our Add test using a table-driven approach (and delete calc_2_test.go for clarity):

// calc_test.go
package calc

import "testing"

func TestAddTableDriven(t *testing.T) {
    tests := []struct {// Define a struct for each test case and create a slice of them
        name string
        a, b int
        want int
    }{
        {"both positive", 2, 3, 5},
        {"positive + zero", 5, 0, 5},
        {"negative + positive", -1, 4, 3},
        {"both negative", -2, -3, -5},
    }

    for _, tt := range tests {// Loop over each test case
        t.Run(tt.name, func(t *testing.T) {// Run each case as a subtest
            got := Add(tt.a, tt.b)
            if got != tt.want {// Check the result
                t.Errorf("Add(%d, %d) = %d; want %d", tt.a, tt.b, got, tt.want) // Report failure if it doesn't match
            }
        })
    }
}

Here's how it works:

• We define a slice of structs, each representing a test case.

• Each struct contains the test name, input values, and the expected result.

• We loop over the slice and call t.Run(tt.name, func(t *testing.T) { ... }) to run each test as a subtest.

• If a subtest fails, you can see which one by its name in the output.

$ go test
PASS
ok      _/C_/projects/Articles/Go_Testing       0.452s

Or to see detailed output:

$ go test -v
=== RUN   TestAddTableDriven
=== RUN   TestAddTableDriven/both_positive
=== RUN   TestAddTableDriven/positive_+_zero
=== RUN   TestAddTableDriven/negative_+_positive
=== RUN   TestAddTableDriven/both_negative
--- PASS: TestAddTableDriven (0.00s)
    --- PASS: TestAddTableDriven/both_positive (0.00s)
    --- PASS: TestAddTableDriven/positive_+_zero (0.00s)
    --- PASS: TestAddTableDriven/negative_+_positive (0.00s)
    --- PASS: TestAddTableDriven/both_negative (0.00s)
PASS
ok      _/C_/projects/Articles/Go_Testing       0.385s

Table-Driven Divide Test

We can apply the same pattern to Divide, including checking for divide-by-zero:

// calc_test.go
...
func TestDivideTableDriven(t *testing.T) {
    tests := []struct { // Define test cases
        name     string
        a, b     int
        want     int
        wantPanic bool
    }{
        {"normal division", 10, 2, 5, false},
        {"division by zero", 10, 0, 0, true},
    }

    for _, tt := range tests { // Loop over
        t.Run(tt.name, func(t *testing.T) { // Run subtest
            if tt.wantPanic { // Check for expected panic
                defer func() { // Recover from panic
                    if r := recover(); r == nil {
                        t.Errorf("Divide(%d, %d) did not panic", tt.a, tt.b)
                    }
                }()
            }
            got := Divide(tt.a, tt.b) // Tests that do not panic
            if !tt.wantPanic && got != tt.want {
                t.Errorf("Divide(%d, %d) = %d; want %d", tt.a, tt.b, got, tt.want)
            }
        })
    }
}

This example shows how to handle both normal and panic cases in a single table-driven test:

• The wantPanic field tells the test whether we expect a panic.

• We use defer and recover to check for a panic when needed.

• Normal test cases still check the result as usual.

Run all tests as before:

$ go test -v
=== RUN   TestAddTableDriven
=== RUN   TestAddTableDriven/both_positive
=== RUN   TestAddTableDriven/positive_+_zero
=== RUN   TestAddTableDriven/negative_+_positive
=== RUN   TestAddTableDriven/both_negative
--- PASS: TestAddTableDriven (0.00s)
    --- PASS: TestAddTableDriven/both_positive (0.00s)
    --- PASS: TestAddTableDriven/positive_+_zero (0.00s)
    --- PASS: TestAddTableDriven/negative_+_positive (0.00s)
    --- PASS: TestAddTableDriven/both_negative (0.00s)
=== RUN   TestDivideTableDriven
=== RUN   TestDivideTableDriven/normal_division
=== RUN   TestDivideTableDriven/division_by_zero
--- PASS: TestDivideTableDriven (0.00s)
    --- PASS: TestDivideTableDriven/normal_division (0.00s)
    --- PASS: TestDivideTableDriven/division_by_zero (0.00s)
PASS
ok      _/C_/projects/Articles/Go_Testing       0.321s

Subtest names make it easy to see which case passed or failed.

Exercise

Try creating your own table-driven test for a new function, Subtract(a, b int) int. Include at least four test cases:

• Both positive numbers

• Positive minus zero

• Negative minus positive

• Both negative

Then run your tests and verify the output.

Testing Functions That Return Errors

Many Go functions return an error as the last return value. Writing tests for these functions is slightly different from testing pure functions like our Add or Divide, because you need to check both the result and whether an error occurred.

Safe Divide Function

Let's add a SafeDivide function to return an error instead of panicking:

// calc.go
...
import "fmt"
...
// SafeDivide returns the result of dividing a by b.
// It returns an error if b is zero.
func SafeDivide(a, b int) (int, error) {
    if b == 0 {
        return 0, fmt.Errorf("cannot divide by zero")
    }
    return a / b, nil
}

Writing Tests for SafeDivide()

We can use a table-driven test again:

// calc_test.go
func TestSafeDivide(t *testing.T) {
    tests := []struct {
        name      string
        a, b      int
        want      int
        wantError bool
    }{
        {"normal division", 10, 2, 5, false},
        {"division by zero", 10, 0, 0, true},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got, err := SafeDivide(tt.a, tt.b)
            if tt.wantError {
                if err == nil {
                    t.Errorf("SafeDivide(%d, %d) expected error, got nil", tt.a, tt.b)
                }
                return // stop here, no need to check `got`
            }
            if err != nil {
                t.Errorf("SafeDivide(%d, %d) unexpected error: %v", tt.a, tt.b, err)
            }
            if got != tt.want {
                t.Errorf("SafeDivide(%d, %d) = %d; want %d", tt.a, tt.b, got, tt.want)
            }
        })
    }
}

What's happening here:

• We added a wantError field to indicate whether the test expects an error.

• If an error is expected, we check that err != nil. If not (that is, err == nil), we fail the test.

• If no error is expected, we check both the returned value (got) and that err == nil.

• Using t.Run subtests keeps everything organized and readable.

Running the tests again:

$ go test -v
...
=== RUN   TestSafeDivide
=== RUN   TestSafeDivide/normal_division
=== RUN   TestSafeDivide/division_by_zero
--- PASS: TestSafeDivide (0.00s)
    --- PASS: TestSafeDivide/normal_division (0.00s)
    --- PASS: TestSafeDivide/division_by_zero (0.00s)
PASS
ok      _/C_/projects/Articles/Go_Testing       0.323s

Showing that both normal and error cases are handled correctly.

Exercise

Update your Subtract(a, b int) int function to a SafeSubtract(a, b int) (int, error) variant that returns an error if the result would be negative. Then write a table-driven test that covers:

• A positive result

• Zero result

• A negative result (should return an error)

Best Practices and Tips

Writing tests in Go is straightforward, but there are a few conventions and tips that make your tests more readable, maintainable, and idiomatic:

Name Tests Clearly

First, make sure you use descriptive names for test functions and subtests. A good name explains what you're testing and under what conditions.

Here’s an example:

t.Run("Divide positive numbers", func(t *testing.T) { ... })
t.Run("Divide by zero returns error", func(t *testing.T) { ... })

Keep Tests Small and Focused

Each subtest should verify one thing, and each test function should cover a single function or method.

Try to avoid combining multiple unrelated checks in the same test function, and use table-driven tests help keep multiple similar checks concise without losing clarity.

Use Table-Driven Tests for Repetitive Cases

If you find yourself writing multiple similar test functions, switch to a table-driven pattern. It makes it easier to add new cases, reduces duplicated code, and keeps output organized with t.Run.

Check Errors Explicitly

In Go, functions often return error. So make sure you always check for errors in tests, even if you expect nil.

You can use the wantError pattern in table-driven tests for clarity.

if tt.wantError {
    if err == nil {
        t.Errorf("expected error, got nil")
    }
}

Avoid Panics When Possible

Panics are fine for some internal checks, but in production code, prefer returning an error.

Your tests can check for panics using defer and recover, but this should be the exception rather than the norm.

Run Tests Frequently

Try to make running tests a habit: go test -v ./.... Frequent testing helps catch mistakes early and reinforces TDD practices.

Keep Tests in the Same Package

By convention, tests live in the same package as the code they test. You can create _test.go files for testing, and Go automatically recognizes them.

Only use a separate package calc_test if you want to test your code from the outside, like a consumer. External test packages (just like every other external package) cannot access unexported identifiers.

Use t.Fatalf vs t.Errorf Appropriately

• t.Errorf reports a failure but continues running the test.

• t.Fatalf stops the test immediately, which is useful if subsequent code depends on successful setup.

These tips will help you write clean, maintainable, and idiomatic Go tests that are easy to read and extend. Following these practices early in your Go journey will make testing less intimidating and more effective.

Conclusion

Unit testing in Go may feel different at first, especially if you're coming from ecosystems with heavy frameworks and assertions. But the simplicity of Go's testing tools is one of its strengths: once you understand the conventions, writing, running, and organizing tests becomes predictable and intuitive.

In this guide, you've seen how to:

• Write basic test functions with the testing package

• Run tests from the command line and interpret the results

• Use table-driven tests to cover multiple cases efficiently

• Handle functions that return errors and check for expected failures

Beyond these fundamentals, testing is not just about verifying correctness, it's also about confidence. Well-tested code allows you to refactor, experiment, and add new features with less fear of breaking existing functionality.

As you continue writing Go code, try to integrate testing early, follow the idiomatic patterns you've learned, and explore more advanced topics such as:

• Using mocks or interfaces to isolate dependencies

• Benchmark tests with testing.B

• Coverage analysis with go test -cover

The key takeaway is that testing in Go is accessible, flexible, and powerful, even without fancy frameworks. By building these habits now, you'll write code that's more reliable, maintainable, and enjoyable to work with.

Solutions to Exercises

Subtract Function and Tests

// calc.go
package calc

func Subtract(a, b int) int {
    return a - b
}

// calc_test.go
package calc

import "testing"

func TestSubtractTableDriven(t *testing.T) {
    tests := []struct {
        name string
        a, b int
        want int
    }{
        {"both positive", 5, 3, 2},
        {"positive minus zero", 5, 0, 5},
        {"negative minus positive", -1, 4, -5},
        {"both negative", -3, -2, -1},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got := Subtract(tt.a, tt.b)
            if got != tt.want {
                t.Errorf("Subtract(%d, %d) = %d; want %d", tt.a, tt.b, got, tt.want)
            }
        })
    }
}

SafeSubtract Function and Tests

// calc.go
package calc

import "fmt"

func SafeSubtract(a, b int) (int, error) {
    result := a - b
    if result < 0 {
        return 0, fmt.Errorf("result would be negative")
    }
    return result, nil
}

// calc_test.go
package calc

import "testing"

func TestSafeSubtract(t *testing.T) {
    tests := []struct {
        name      string
        a, b      int
        want      int
        wantError bool
    }{
        {"positive result", 5, 3, 2, false},
        {"zero result", 3, 3, 0, false},
        {"negative result", 2, 5, 0, true},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            got, err := SafeSubtract(tt.a, tt.b)
            if tt.wantError {
                if err == nil {
                    t.Errorf("SafeSubtract(%d, %d) expected error, got nil", tt.a, tt.b)
                }
                return
            }
            if err != nil {
                t.Errorf("SafeSubtract(%d, %d) unexpected error: %v", tt.a, tt.b, err)
            }
            if got != tt.want {
                t.Errorf("SafeSubtract(%d, %d) = %d; want %d", tt.a, tt.b, got, tt.want)
            }
        })
    }
}

While this brings an increase in productivity, there's a growing downside. AI-generated code is prone to errors, unexpected bugs, or poor integration with the rest of your code.

Because of these risks, it’s more important than ever to establish robust testing practices to make sure your code is high quality and properly functioning. Various testing tools are available to help solve these challenges, and pytest stands out in the Python ecosystem for its simplicity, flexibility, and powerful features.

In this article, we'll explore the following topics:

Table of Contents

• Why Use pytest?

• How to Write Your First Tests with pytest

• How to Run pytest Tests

• How to Interpret pytest Results

• How to Handle Exceptions in pytest

• Advanced pytest Features

  • 1. pytest Markers

  • 2. pytest Fixtures

  • 3. Parametrization

  • 4. pytest Plugins

• Conclusion

By the end of this article, you will have a comprehensive knowledge of pytest and be able to use it in your Python development process.

Pre-requisites

• Must have Python installed

• An understanding of the Python programming language

Why Use pytest?

pytest is a popular testing framework for Python that makes it easy to write and run tests. Unlike unittest and other Python testing frameworks, pytest’s simple syntax allows developers to write tests directly as functions or within classes. This lets you write clean, readable code without complexities.

pytest also supports popular Python frameworks like Flask, Django, and more. Combined with other rich features, pytest equips you with the tools you need to ship reliable software in today’s AI-driven era.

Key features of pytest that make it a preferred testing tool include:

• Flexibility: it provides flexibility in test structure by supporting tests for functions, classes, and modules.

• Detailed test output: it provides a detailed and readable test output, making it easy to understand test failures and errors.

• Automatic test discovery: it automatically discovers tests by looking for files that start with "test_" or end with "_test.py". This eliminates the need for manually specifying test files**.**

• Parameterization: it supports parameterized tests, which allow you to run a single test function with multiple sets of inputs.

• Fixtures: it fixtures provide setup and tearDown methods that help prevent code repetition. This enables you to set up baseline conditions for your tests and also delete them after each test.

• Plugins and extensions: it has a rich ecosystem of plugins and extensions that add extra functionalities, such as detailed tests reporting, and integration with other tools and Python frameworks like Django and Flask.

• Compatibility: it is compatible with other testing frameworks like unittest , allowing you to migrate tests from different testing frameworks and run them seamlessly on it.

How to Write Your First Tests with pytest

This section will guide you through writing your first set of tests using the pytest framework.

pytest is a Python package, and you’ll need to install it before using it. You can do that with the following command:

pip install pytest

NOTE: Following Python's best practices, it’s recommended you install pytest within a virtual environment. Here's a guide to help you set it up.

Next, create a Python file where you will write your tests and import pytest into it using:

import pytest

pytest has 2 basic methods of writing tests, which include:

• The function-based method: This method is straightforward for writing tests because you write the tests in individual functions.

  Note: Each function name must be prefixed with the word test_ for pytest to discover and run these tests automatically.

  Here’s an example of a function-based test:

    def test_addition():
        assert 1 + 1 == 2
  

  Note: In the code above, the assert statement used here in pytest is Python’s built-in “assert”. It’s more convenient and doesn’t require the specific methods like assertEqual and assertTrue which are common with unittest. Another advantage of using the assert statement is that it provides more detailed error messages when an assertion fails.

• Class-based method: This method is similar to the way of writing tests in unittest, except that your test class does not inherit any methods. An example is shown below:

    class TestMathOperations:
        def test_addition(self):
            assert 1 + 1 == 2
  

  This method of writing tests in pytest is useful when you want to group related tests together.

How to Run pytest Tests

Running pytest differs slightly from the normal convention of running regular Python scripts.

The general method of running pytest tests is by running the pytest command in your terminal. pytest will automatically look for and run all files of the form test_*.py or *_test.py in the current directory and subdirectories. But while this may be a great way to run tests, pytest offers more flexibility beyond this general method of running tests.

Depending on preferences, you may want to run your test files based on the following:

1. To run a specific test file: To run tests in a specific file, use the pytest command followed by the file name. For example: pytest test_example.py.

2. To run tests in a directory: Let’s say you have a directory named Tests that contains some test files. To run all the tests in that directory, use the pytest command followed by the directory and a forward slash. For example: pytest Tests/.

3. To run tests using specific keywords: To run tests based on a certain keyword, use the command pytest -k "keyword". Pytest will automatically look for and run function names, class names, or file names matching that keyword in the current directory and subdirectories. But to run tests matching a certain keyword in a specific file, you’d have to specify the file name after the pytest command. For example: pytest test_example.py -k "keyword".

4. Run a specific test within a test file: To run only a specific test inside a test file, use the command pytest test_example.py::test_addition. This will run only the test_addition test function within the test_example.py module.

5. To run all test methods in a specific class: To run all the tests within a specific class, use pytest test_example.py::TestClass. This command would run all the test methods inside the TestClass class in the test_example.py module.

6. To run a specific test method inside a specific class: To run a specific test inside a specific class, use pytest test_example.py::TestClass::test_addition. This command would run the specific test_addition method within the TestClass class in the test_example.py module.

How to Interpret pytest Results

One major advantage pytest has over other Python testing frameworks is the rich output it provides, which gives very detailed information about the status of your tests.

Let’s use a basic test to understand how to interpret pytest’s output:

import pytest

def test_addition():
    assert 1 + 1 == 3

Run this test, and we get an output similar to the one below:

============================== test session starts ====================================
platform win32 -- Python 3.10.5, pytest-8.4.1, pluggy-1.6.0
rootdir: C:\\Users\\hp\\Desktop\\Pytest
collected 1 items

                                                                                  [ 50%]
test_example.py F                                                                 [100%]

===================================== FAILURES =========================================
____________________________________test_addition ______________________________________

    def test_addition():
>       assert 1 + 1 == 3
E       assert (1 + 1) == 3

test_example.py:4: AssertionError
============================== short test summary info =================================
FAILED test_example.py::test_addition - assert (1 + 1) == 3
========================= 1 failed, 1 passed in 0.13s ==================================

The above output is divided into several sections. Here’s a breakdown of what each section means:

1. Test session information:

    =============================== test session starts ===============================
    platform win32 -- Python 3.10.5, pytest-8.4.1, pluggy-1.6.0
    rootdir: C:\\Users\\hp\\Desktop\\TDD pytest
    collected 1 item
   

   • This section displays a summary of the test environment. It begins with a line marker that indicates the beginning of the test session.

   • Below the marker, pytest displays information about the operating system, along with the installed versions of Python, pytest and pluggy. (Pluggy is a pytest dependency used to manage plugins.)

   • The next line indicates the root directory where the test is being run.

   • The last line in this section displays the number of tests found in this directory.

2. Test status:

    test_example.py F                                                              [100%]
   
    ================================== FAILURES =========================================
    ________________________________ test_addition ______________________________________
   
        def test_addition():
    >       assert 1 + 1 == 3
    E       assert (1 + 1) == 3
   
    test_example.py:4: AssertionError
   

   • This section displays information about the status of our tests

   • The first line in this section specifies the test file which is being run, followed by the status (F in this case, which indicates a test failure).

   • The next set of lines gives specific information about the failed tests. This includes the function where the failure occurred (test_addition), and the exact line of code responsible for the error.

   • The last line gives a concise summary of this section. It indicates that the error occurred in test_example.py on line 4 and it was an AssertionError.

3. Test summary:

    ============================= short test summary info =============================
    FAILED test_example.py::test_addition - assert (1 + 1) == 3
    ================================ 1 failed in 0.13s ================================
   

   • This section provides an overall summary of the test.

   • It indicates that the failed test occurred in test_example.py file in the test_addition function because of an incorrect assertion (1 + 1) == 3 which isn’t true.

Edit the code with the correct assertion assert(1 + 1) == 2 and rerun the code. This time, the code passes with a different output.

=============================== test session starts ==================================
platform win32 -- Python 3.10.5, pytest-8.3.2, pluggy-1.5.0
rootdir: C:\\Users\\hp\\Desktop\\TDD pytest
collected 1 items

test_example.py .                                                               [100%]

=============================== 1 passed in 0.01s =================================

How to Handle Exceptions in pytest

Exceptions are unexpected errors that occur while running our tests, and they prevent our code from performing as expected. As a result, pytest offers several built-in mechanisms for handling these exceptions (but we’ll just cover one of them in this article).

pytest.raises Context Manager is a tool that checks if your code raises specific exceptions. If the specified exception is raised, that test passes, confirming that the expected error occurred. But if the specified exception is not raised, that test fails.

Usage Examples of pytest.raises

1. Checking for ValueError: In Python, a ValueError is raised when a function receives an argument with an incorrect value. In the example below, we can verify that a ValueError is raised when attempting to calculate the square root of a negative number.

    import pytest
    import math
   
    def calculate_square_root(value):
        if value < 0:
            raise ValueError("Cannot calculate the square root of a negative number")
        return math.sqrt(value)
   
    def test_calculate_square_root():
        with pytest.raises(ValueError):
            calculate_square_root(-1)
   

2. Checking for ZeroDivisionError: Dividing a number by zero raises a ZeroDivisionError. In this example, we check that this error is raised when dividing a number by zero.

    import pytest
   
    def divide_numbers(numerator, denominator):
        return numerator / denominator
   
    def test_divide_numbers():
        with pytest.raises(ZeroDivisionError):
            divide_numbers(10, 0)
   

3. Checking for TypeError: A TypeError is raised when an operation is applied to an object of an inappropriate type. Here, we check that this error is raised when adding incompatible data types, such as a string and an integer given in the example.

    import pytest
   
    def add_numbers(a, b):
        return a + b
   
    def test_add_numbers():
        with pytest.raises(TypeError):
            add_numbers("10", 5)
   

4. Checking for KeyError: A KeyError is raised when we try to access a dictionary key that doesn’t exist. We can verify and handle this error using the following code:

    import pytest
   
    def get_value(dictionary, key):
        return dictionary[key]
   
    def test_get_value():
        with pytest.raises(KeyError):
            get_value({"name": "Alice"}, "age")
   

Advanced pytest Features

As a robust testing framework, pytest offers some advanced features that help you manage complex test scenarios. In this section, we will explore some of these advanced features at a beginner-friendly level and demonstrate how you can start applying them in your tests.

1. pytest Markers

When working with a large codebase, sometimes running every single test can be time-consuming. This is where pytest markers come in handy.

A marker is just like a label that you can attach to a test function to categorise it. Once a test is labelled, you can instruct pytest to run only tests with certain markers. For example, you may label some tests as "slow" if they take longer to execute and run them separately from the faster ones.

One advantage to using Markers is that it allows you to run specific tests based on categories or specific parameters, and also skip tests if certain conditions aren’t met.

pytest comes along with some built-in markers that can be quite useful:

1. @pytest.mark.skip: This marker allows you to skip a test unconditionally, and can be useful when you know a test will fail due to an external issue or incomplete code.

   Example:

    @pytest.mark.skip(reason="Feature not yet implemented")
    def test_feature():
        pass
   

2. @pytest.mark.skipif: This marker allows you to skip a test conditionally if certain conditions are met.

   Example:

    import sys
   
    @pytest.mark.skipif(sys.platform == "win32", reason="does not run on windows")
    class TestClass:
        def test_function(self):
            "This test will not run under 'win32' platform"
   

3. @pytest.mark.xfail: This marker is attached to tests that are expected to fail, probably due to a bug or incomplete feature. So when pytest runs such tests, it won’t count it as a failure.

   Example:

    @pytest.mark.xfail(reason="division by zero not handled yet")
    def test_divide_by_zero():
        assert divide(10, 0) == 0
   

   Note: Detailed information about skipped/failed tests is not shown by default to avoid cluttering the output.

While pytest comes along with some built-in markers, you can also create your own custom marker (but we won’t cover that in this tutorial). Kindly refer to the documentation for more information on working with custom markers

2. pytest Fixtures

In pytest, fixtures allow you to create reusable default data that can be shared across multiple tests. By using fixtures, you can reduce code repetition, making your tests cleaner and more maintainable.

In pytest, fixtures are defined with the @pytest.fixture decorator as shown in the example below:

Let’s say we have several tests that rely on a list of user data. Instead of repeating the same data in each test, we can create a fixture to hold this data, and the fixture is passed across the tests that need it.

import pytest

@pytest.fixture
def user_data():
    return [
        {"name": "Alice", "age": 30},
        {"name": "Bob", "age": 25},
        {"name": "Charlie", "age": 35}
    ]

# Test function to check for a specific user by name and age
def test_user_exists(user_data):
    user = {"name": "Alice", "age": 30}

    # Check if the target user is in the list
    assert user in user_data

# Test average age of users
def test_average_age(user_data):
    ages = [user["age"] for user in user_data]
    avg_age = sum(ages) / len(ages)
    assert avg_age == 30

Note: The @pytest.fixture decorator in the code above marks the user_data function as a fixture in pytest. This fixture provides reusable data that can be shared across multiple test functions, allowing them to share the same setup without repeating code.

3. Parametrization

Parametrization is a pytest feature that allows you to run a test function with different sets of data at once.

For example: Let’s say you have a function that calculates the square of a number. To provide enough coverage while testing, you would want to test the function with zero, positive, and negative numbers.

Instead of writing separate test functions for each scenario, you can use parametrization to run a test function with different sets of data at once. This approach is more concise, and reduces code duplication.

To use parametrization in pytest, we use the @pytest.mark.parametrize decorator as shown in the example below:

import pytest

# Function to calculate the square of a number
def square_numbers(num):
    return num * num

#Parametrize decorator to test the square function with different inputs
@pytest.mark.parametrize("input_value, expected_output", [
    (2, 4),     
    (-3, 9),    
    (0, 0)    
])

def test_square(input_value, expected_output):
    assert square_numbers(input_value) == expected_output

In the example above, the different input values and expected values are listed in the @pytest.mark.parametrize decorator. We’re testing the square_numbers() function with three different input values: 2, -3, and 0.

For each value, pytest calls the test_square() function and compares the result of square_numbers(input_value) to expected_output.

This approach is more efficient and ensures the function behaves as expected across a variety of cases.

4. pytest Plugins

Plugins are an extension mechanism that allows you to add new functionality to pytest or modify its existing behaviour. These plugins work by providing additional features that extend pytest’s capabilities, which can be useful, especially in complex test scenarios.

pytest has a vast ecosystem of plugins, each designed to suit your different testing needs. You can find the full list of available plugins on PyPI in the pytest Plugin List.

To use a plugin, simply install it with pip.

For example:

pip install pytest-NAME
pip uninstall pytest-NAME

Note: NAME in the code above should be replaced with the name of the plugin you want to install.

After installing a plugin, pytest automatically finds and integrates it. There’s no need for any additional configuration.

In this section, we explored some of pytest's advanced features. By leveraging these features, you can now significantly improve the quality of your tests by ensuring they’re more efficient, scalable, and easier to maintain over time.

Conclusion

In this article, you’ve learned the basics of testing with pytest, from writing and interpreting tests to handling exceptions and using advanced features like fixtures and parametrization.

Whether your code is written manually or generated by AI, learning how to write tests empowers you to detect bugs early, and build more reliable software. Testing acts as a safety net that boosts you confidence during development and ensures your code works as expected.

If you're ready to go a step further, I’ve written an in-depth article on Test Driven Development in Python. It is a powerful approach where writing tests guides your entire coding process.

If you found this helpful, let me know, share it with your network, or give it a like to help others discover it too.

In software development, it's beneficial to break your application into small, isolated units. This approach allows you to write independent tests to check all parts of your application, ensuring that they behave as expected. Also, if a test fails, you can easily isolate and troubleshoot the area of the code that has the bug without tampering with the rest of your application.

Python provides built-in support for unit testing through the unittest testing framework. There are also other third-party testing frameworks that you can use for your unit testing, such as pytest.

This article focuses on how to use the unittest framework to write tests for your Python applications and why developers often prefer it.

To get the best out of this article, you should have a basic understanding of the Python programming language.

Why Do Developers Prefer to Use unittest?

While there are many frameworks for unit testing in the Python ecosystem, many developers still prefer the built-in unittest due to its compelling advantages.

First, the unittest module is part of Python's standard library. This ensures immediate availability and compatibility across various environments without extra dependencies. The seamless integration with various environments makes it convenient for developers to use unittest without installing additional packages.

Second, as a long-standing framework within the Python ecosystem, unittest benefits from familiarity and longevity. Many developers are already used to its API and structure, making it a reliable choice for testing.

Third, most integrated development environments (IDEs) such as PyCharm offer built-in support for unittest. This improves developer productivity and streamlines the testing process, allowing for easier test management and execution.

Fourth, the framework has comprehensive and well-maintained documentation. This provides detailed guidance and examples, aiding developers in effectively using unittest for their testing needs.

Finally, many existing Python projects use unittest for testing, ensuring compatibility with legacy codebases. This widespread adoption allows developers to maintain and extend older projects without needing to introduce and adapt to a new testing framework.

How to Write Unit Tests with unittest

Unit testing with unittest involves creating test cases to verify the functionality of individual units of your code. Each test case is defined by subclassing unittest.TestCase. This allows you to inherit the several methods provided by the TestCase class.

Some of the methods provided by the TestCase class are assert methods. These assert methods allow you to check whether the actual result of a function or operation matches the expected result, or whether certain conditions are met. If an assertion fails, the test is marked as failed, and you will receive an error message.

See Classes and functions for detailed information about the different methods provided by the TestCase class.

Now, let's use two of the assert methods to write tests for a simple calculator program. First, create a new folder (directory), named unit-testing. Then, create a file named calculator.py within your unit-testing folder. Now, copy the following code into your calculator.py file:

def add(x, y):
    """add numbers"""
    return x + y

def subtract(x, y):
    """subtract numbers"""
    return x - y

def divide(x, y):
    """divide numbers"""
    return x / y

def multiply(x, y):
    """multiply numbers"""
    return x * y

Notice that instead of having your calculator program within a single function, we broke it into four independent functions (units). This is to ensure that each part of the program is independently tested. So if any of the units gives an error during testing, you can easily identify that unit and troubleshoot it without tampering with the other parts of your program.

As earlier mentioned, testing with unittest involves creating a subclass of the unittest.TestCase class and then defining methods within the subclass to test individual units of your program.

To show how this works, let's write a test for the add function in your calculator program. In your unit-testing folder, create a new file named test_calculator.py and then copy the following code into it:

import unittest
import calculator

class TestCalculator(unittest.TestCase):
    def test_add(self):
        self.assertEqual(calculator.add(1, 2), 3)
        self.assertEqual(calculator.add(-1, 1), 0)
        self.assertEqual(calculator.add(-1, -1), -2)
        self.assertEqual(calculator.add(0, 0), 0)

In lines one and two of your code, you imported the unittest and your calculator modules. You then created a TestCalculator class, which inherits from the TestCase class.

In line five of your code, you defined a test_add method within your class. The method just like every instance methods in Python takes self as its first argument. Since self is a reference of the TestCalculator class, it can access the assertEqual method provided by the TestCase class, which TestCalculator inherits from.

The assertEqual method checks if two values are equal. It has the following syntax:

self.assertEqual(first, second, msg=None)

In the preceding syntax, first represents the value you want to test against the second value. msg is optional and it represents a custom message that you will receive if the assertion fails. If you don't provide a value for msg, you will receive a default message.

Now, let's use the explanation of the syntax to explain the use of assertEqual in your test_add method. In your first assertion, self.assertEqual(add(1, 2), 3) checks if the result of add(1, 2) is equal to 3. If the function returns 3, the test passes. Otherwise, it fails and outputs a message indicating the mismatch. This explanation is the same for the rest of your assertions.

Also, notice that you tested just representative values in your test_add method. This ensures that your test covers a wide range of possible inputs without redundant code. Here is a breakdown of the representative values in your test_add method:

• The addition of two positive numbers (self.assertEqual(calculator.add(1, 2), 3)).

• The addition of a negative number and a positive number (self.assertEqual(calculator.add(-1, 1), 0)).

• The addition of two negative numbers (self.assertEqual(calculator.add(-1, -1), -2)).

• The addition of two zeros (self.assertEqual(calculator.add(0, 0), 0)).

Now, to run your test, navigate to the unit-testing directory in your terminal and run the following command:

python -m unittest test_calculator.py

Running the preceding command will give you the following message in your terminal:

.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK

The output indicates that you ran a single test and it was successful.

To ensure that your test is working as expected, you go back to your calculator.py file and change the addition (+) operator in your add function to subtraction (-), like this:

def add(x, y):
    """add numbers"""
    return x - y

Once you've made the changes, running your test again will raise an AssertionError showing that your test failed:

Traceback (most recent call last):
  File ".../test_calculator.py", line 6, in test_add
    self.assertEqual(calculator.add(1, 2), 3)
AssertionError: -1 != 3

----------------------------------------------------------------------
Ran 1 test in 0.000s

You may be wondering why you have to include the unittest module in your command instead of running python test_calculator.py. That's because you are yet to make your test_calculator.py file a standalone script. So running python test_calculator.py won't give you any output.

To make your test_calculator.py executable as a standalone script, you need to add the following to the bottom of your test_calculator.py file:

if __name__ == "__main__":
    unittest.main()

Also, the unittest module requires that you start the name of your test methods with the word test, otherwise, your test won't run as expected.

To try this, change the name of your test_add method to add_test like this:

class TestCalculator(unittest.TestCase):
    def add_test(self):
        self.assertEqual(calculator.add(1, 2), 3)
        self.assertEqual(calculator.add(-1, 1), 0)
        self.assertEqual(calculator.add(-1, -1), -2)
        self.assertEqual(calculator.add(0, 0), 0)

Now, if you run the command python test_calculator.py, you will get a message similar to this:

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK

Notice that the preceding output shows that zero tests ran. Now, change your method's name back to test_add. Also, change the operator in the add function of your calculator.py back to addition (+). Now, rerun the test with the command python test_calculator.py and compare your output to the preceding output.

It's a common practice for developers to handle invalid input by raising exceptions. So, it's important to write tests that check for these exceptions.

For example, Python will raise a ZeroDivisionError if you try to divide any number by zero. You can use the unittest module to test for such errors.

Now, modify your test_calculator.py file to include a test method for your divide function:

import unittest
import calculator

class TestMathOperations(unittest.TestCase):
    def test_add(self):
        self.assertEqual(calculator.add(1, 2), 3)
        self.assertEqual(calculator.add(-1, 1), 0)
        self.assertEqual(calculator.add(-1, -1), -2)
        self.assertEqual(calculator.add(0, 0), 0)

    def test_divide(self):
        self.assertEqual(calculator.divide(10, 2), 5)
        self.assertEqual(calculator.divide(9, 3), 3)
        self.assertEqual(calculator.divide(-6, 2), -3)
        self.assertEqual(calculator.divide(0, 1), 0)
        with self.assertRaises(ZeroDivisionError):
            calculator.divide(10, 0)

if __name__ == "__main__":
    unittest.main()

In the preceding code, your new test_divide method tests representative values just like your test_add method. But there is new code at the end that uses assertRaises. assertRaises is another assert method provided by unittest to check if your code raises an exception. Here, you used the method to check for ZeroDivisionError.

So, if you run the tests now, you will get a message showing two dots (..) and indicating that you ran two successful tests:

..
----------------------------------------------------------------------
Ran 2 tests in 0.000s

OK

Conclusion

This article has taught you the basics of unit testing in Python using the unittest testing framework.

You've learned the importance of independently testing individual units of your application and the reasons unittest is still a popular choice among Python developers. Also, you've learned how to write basic test cases for the add and divide functions in your simple calculator program.

With this knowledge, you can now confidently create tests that ensure your code behaves as expected, making it more robust and maintainable. I encourage you to apply these lessons by writing tests for the remaining subtract and multiply functions in your calculator program.

• Understanding mocking: Why it's necessary for building a robust testing strategy.
• Exploring some of the most common mocking libraries: Such as Moq, NSubstitute, FakeItEasy, and Rhino Mocks.
• Mastering mocking techniques: Using each of these libraries, equipping you with the knowledge to choose the best mocking tool for your needs.

The aim of this tutorial is to give you the knowledge to make up your own mind on which mocking library you prefer, so you can go forward and write some powerful tests in your application.

Prerequisites for this tutorial

1. Understanding of C# programming
2. Understanding of C# Unit Testing
3. An IDE (Rider, Visual Studio, and so on), or Code Editor (VS Code, Sublime Text, Atom, and so on)

Getting Started/Setup

To speed up the process, I've made a public GitHub repo available for this tutorial,. You can clone and use it on your local machine to follow along.

Simply navigate to this link and clone the repo to your local machine.

Quick refresher if you've forgotten to do that: go to the link above, and in the top right corner click "Code", and then copy the URL provided.

Find your local git folder, (if you don't have one, create one in your user root folder). Then in your preferred terminal navigate to your git older, and execute the following command.

// (replacing <url> with the url)
git clone <url>

A Brief Overview of the Application

The solution you've just cloned is a basic Web API project which references a class library with some Todo domain objects and services which will alter a list of todo items.

For the purpose of this tutorial, these elements are stored in an in-memory list, rather than connecting to a database. But you can use a database or other forms of data persistence methods.

However, for the purpose of this tutorial, we're less concerned with persisting the data, and more so around mocking this service.

What Is Mocking?

With mocking you won't tell the difference

Mocking in software development is the concept of simulating a behavior or returned object of a class, method or service that another part of the system under test depends on.

When testing a particular component or unit of code, it's often necessary to isolate it from its dependencies, such as databases, web services, or other classes, in order to ensure that the test focuses solely on the functionality of the unit being tested rather than concerning itself with external aspects of the code.

Mocking allow developers to create mock objects or dummy implementations of these dependencies that behave in a predetermined way, mimicking the behavior of the real objects.

By using mocked objects or methods, we can control the input and output of the dependencies. This makes it a lot easier to test different scenarios, where business logic is dependent on the outcome of a dependency.

Example

Let's say we have a API endpoint that calls a repository which connects to a database. Our API response type depends on the returned value from the repository: we either return a 400 or a 200 response from our API.

We can simply mock the repository return value, and test that our API returns the correct response in both scenarios without having to actually touch our database at all.

In essence, mocking helps developers write more reliable and efficient tests by isolating the code under test and providing predictable behaviour for its dependencies, thereby improving the overall quality of the software.

What Are the Benefits of Mocking?

Benefits

Code Isolation

As I've already explained, mocking dependencies allows for isolation of code for testing. By mocking the dependencies, you can assert the points of failure in the code under test, and not the dependencies themselves (unless you mock them incorrectly – which hopefully this tutorial will help you avoid).

Faster Testing

By replacing real dependencies with mocked implementations, testing can be performed faster. You're not battling with inconsistencies, unreliable or unpredictable outcomes from those dependencies. It eliminates the need for setting up and tearing down external sources, which can sometimes be complex and time consuming.

Deterministic Testing

Mock objects offer a controlled environment, allowing developers to specify the exact behavior and responses of dependencies. This approach means that the tests are consistent, making it easier to find bugs and debug issues, especially those adopting a TDD (Test Driven Development) approach.

Parallel Testing

Mocking enables parallel testing (multiple tests being ran at the same time) by removing dependencies on external resources that may be limited or inaccessible during testing.

For example if you weren't mocking your database connection layer, trying to run tests in parallel may cause inconsistent pass/fail metrics, as another test could be affecting the database table you're utilizing in another test. Mocking this layer means your tests are now agnostic to this layer, and can be ran at the same time.

Reduced Test Maintenance

Since mock objects encapsulate the behavior of dependencies, changes to those dependencies do not necessarily require updates to the tests themselves. This reduces the maintenance overhead associated with evolving codebases and dependencies.

Enhanced Test Coverage

Mocking allows developers to simulate a wide range of scenarios and edge cases. By controlling the behavior of dependencies, developers can ensure that their tests exercise all relevant paths through the code, removing any real life or physical limitations.

Things To Be Aware of With Mocking

Complexity: Sometimes when mocking/testing complex areas of the application, mocking can also become complex. However, if the system is too difficult to mock, you may need to reassess your architecture.

Learning Curve: It requires an understanding of the syntax and concepts of the mocking library, which can be challenging for developers who are new to unit testing or the specific framework.

Over-specification: Mocking can lead to over-specifying the behavior of the code under test. This means that tests may become tightly coupled to the implementation details, making them brittle and prone to breaking when the implementation changes. It's essential to strike a balance between verifying behavior and focusing on the desired outcomes.

Be mindful of false-positive tests: While mocking allows you to isolate units of code, it may also create a false sense of security. Mocks simulate dependencies, but they may not fully replicate the behaviour of the real dependencies. Integration tests or end-to-end tests are still necessary to verify the system's behavior as a whole.

Popular .NET Mocking Libraries

Here are some popular .NET testing libraries:

• FakeItEasy
• NSubstitute
• Moq
• Rhino Mocks

These are just a list of the most commonly used .NET mocking libraries available online, but there are many more. I'd highly recommend using one of these as they have a larger community, more reputable code base, and good documentation (vital when starting out).

Each of these mocking libraries have their own syntax for creating mocks of objects however they all follow the same principles.

1. Declare the object/type/service you'd like to mock
2. How you want that object/type/service to run (the implementation)
3. What is the returned value (where necessary).

Looking at the Tests

If you open the solution, and navigate to the "Test" project, you can see that we have four files with each of the different mocking library tests in there.

1. FakeItEasyApiTests.cs
2. MoqApiTests.cs
3. NSubstituteApiTests.cs
4. RhinoMocksApiTests.cs

Within these files, you will see that we have four very basic XUnit tests. I've kept them brief and simple for the purpose of this tutorial.

Deep Dive Into the Test Structure

Each test file uses a constructor to initialize a private version of their respectable services, and you can see how these differ from one library to the next, yet still follow the same concepts.

// FakeItEasy
 _fakeTodoService = A.Fake<ITodoService>();

// NSubstitute
  _substituteTodoService = Substitute.For<ITodoService>();

// Moq
 _mockTodoService = new Mock<ITodoService>();

// Rhino Mocks
 _mockTodoService = MockRepository.GenerateMock<ITodoService>();

Choosing the "right" mocking library all comes down to personal preference, and what you feel is easier to write, work with and read/understand.

Some may find the use of words like Fake, or Substitute.For easier to comprehend or read. Whereas others may find the A.Fake unintuitive and prefer new Mock<type> more obvious.

Arrange, Act and Assert

Following the testing principle of AAA (Arrange, Act and Assert) we can carefully structure our tests, making it obvious what we're doing and where.

The AAA approach to testing involves three steps:

1. Arrange: Set up the test environment, mocked services/external dependencies.
2. Act: Perform the action being tested.
3. Assert: Verify the expected outcome.

Using Mocks to Simulate Returned Items

Let's test the getAll (GetAllTodoItems) endpoint by mocking the TodoService.GetAllTodos method to return a stubbed list of tasks.

This approach eliminates the need to set up and seed a database for each test scenario, ensuring focused testing of API endpoint returning values against specific criteria.

Mocks provide an ideal solution, allowing us to simulate the desired behavior without interference from other tests.

We can do this like so (remember the full code is available in the repo):

// FakeItEasy
A.CallTo(() => _fakeTodoService.GetAllTodos()).Returns(expectedTodos);

// NSubstitute
 _substituteTodoService.GetAllTodos().Returns(expectedTodos);

 // Moq
 _moqTodoService.Setup(s => s.GetAllTodos()).Returns(expectedTodos);

 // Rhino Mocks
 _mockTodoService.Stub(s => s.GetAllTodos()).Return(expectedTodos);

What are these methods doing?

A common feature you will see across the majority of libraries is the usage of lambda functions to dictate which method is being mocked.

The lambda function provided in the setup method is essentially a configuration step that defines what action should be taken when the mocked method is called. This configuration is stored and applied when the mocked method is invoked during the test.

Let's break it down, what we're doing:

1. The lambda specifies which method on the mocked service we wish to configure/setup.

2. The lambda we pass in isn't ran straight away by the setup method. We're not telling the test to run the method immediately; we're saying, "Remember this instruction/setup for when the actual method is called during the test."

3. When the method we're mocking gets called during the test then it checks if the call signature matches a setup configuration we've provided. If it matches, the test follows the instructions given during setup.

Important Notes:

NSubstitute, on the other hand, allows the developer to mock the method directly on the fake object. This means that you can access the fake GetAllTodos method and simply set the return value to your expected value.

Although Moq uses a Setup method, it differs ever so slightly from the other methods. Moq internally creates a proxy object that represents the mocked object, and exposes a .Object property to access it. We'll see how this works in the next part.

How to Call The System Under Test (SUT)

// FakeItEasy
var sut = new TodoController(_fakeTodoService);

// NSubstitute
var sut = new TodoController(_substituteTodoService);

// Moq -- slightly different to the others
 var sut = new TodoController(_moqTodoService.Object);

// Rhino Mocks
var sut = new TodoController(_mockTodoService);

In three of the four libraries, you can pass the mocked object directly. However, Moq requires accessing the .Object property on the mock to use it. Thus, we passed moqTodoService.Object as an argument to the controller.

an image showing that all the tests passed

Running the tests, you can see they all pass. Should you change any of the code in the repository, it would not make any difference as the repo is mocked in these tests. Have a go, try changing the repo functionality and re-running the tests, they will continue to pass.

We are concentrating on the functionality of the endpoint, not what the mocked repo is doing, and this is the beauty of mocking.

The Options with Mocking Are Endless

Mocking doesn't just allow us to set what is returned from a mocked object, it can also allow us to mock the implementation, including the ability to throw specific errors so we can test our API error handling and unhappy paths too.

This is illustrated in the Delete_Returns500_AndErrorMessageThrown_WhenExceptionThrown test within each library test file.

// FakeItEasy
A.CallTo(() => _fakeTodoService.Delete(1)).Throws(new Exception(errorMessage));

// NSubstitute
_substituteTodoService.When(x => x.Delete(1)).Do(x => throw new Exception(errorMessage));

// Moq
_moqTodoService.Setup(s => s.Delete(1)).Throws(new Exception(errorMessage));

// Rhino Mocks
 _mockTodoService.Stub(s => s.Delete(1)).Throw(new Exception(errorMessage));

Using the different libraries, we can make the Delete method on the service throw whatever exception we'd like to. This is ideal for when you want to return different status codes, or handle errors in different ways depending on the type of exception thrown.

As an example we could change Throws(new Exception(errorMessage) to Throws(new UnauthorizedAccessException() and test that if a 401 status code is returned when thrown.

Global Setup

You can assign multiple configurations to the same method. This is great in situations where you want to set up all your configurations of the mocked object in one place. For example, in the test class constructor.

In some test frameworks (like NUnit) you can use a [OneTimeSetUp] attribute above your method, which is ran before your test cases, or simply use your test class constructor.

In this scenario you could do something (in Moq) like:

public MoqApiTests()
{
        _mockTodoService = new Mock<ITodoService>();
        _mockTodoService.Setup(x => x.Delete(1)).Throws(new Exception("This is a generic exception"));
        _mockTodoService.Setup(x => x.Delete(2)).Throws(new UnauthorizedAccessException("You cannot perform this action on this item"));
}

In this example, we demonstrate setting up mocked service calls to the same method with various arguments, each causing it to throw different exceptions.

This approach is beneficial for testing different outcomes when different exceptions occur in separate tests, without cluttering our test code with repetitive setup.

For example:

// Test 1
var result = TodoController.Delete(1);
// Assert handles general exception

// Test 2
var result = TodoController.Delete(2); 
// Assert handles UnauthorizedAccessException

I prefer to set up mocks within each individual tests to ensure there are no external factors influencing the mock.

This way, I can easily identify what is being mocked within the test without searching for the mocked object and setup elsewhere.

What If I Don't Care What I'm Passing In?

In our deletion examples, we consistently passed an ID to the mock implementation. Consequently, if we were to call the method with a different ID like 101 through the TodoController.DeleteTodoItem call, we wouldn't receive the same result.

This is because we explicitly instructed the mocked object to throw an error when the stubbed method is called with an ID of 1.

To address this issue, we can be less specific. Each library has its own syntax for this, enabling us to specify that if any integer is passed to the method, it will throw a particular exception.

// FakeItEasy
A.CallTo(() => _fakeTodoService.Delete(A<int>._)).Throws( new Exception(errorMessage));

// NSubstitute
_substituteTodoService.When(x => x.Delete(Arg.Any<int>())).Do(x => throw new Exception(errorMessage));

// Moq
_mockTodoService.Setup(s => s.Delete(It.IsAny<int>())).Throws(new Exception(errorMessage));

// Rhino Mocks
_mockTodoService.Stub(s => s.Delete(Arg<int>.Is.Anything)).Throw(new Exception(errorMessage));

This code indicates that when any argument of type int is passed, it should throw this exception.

NSubstitute differs slightly in syntax: it requires explicit instruction to throw the specified error when encountering this scenario, unlike when were were informing it to return an object. This difference stems from the internal mechanisms of the library.

Asserting Mocks Are Called

In some cases, you might want to verify that a mocked service is called with the correct arguments. This is particularly useful when dealing with a "fire-and-forget" service.

In this scenario, your API endpoint is called, and while it always returns true, it also triggers a service to perform some action independently, which doesn't affect the API's return type (perhaps an asynchronous notification service).

This is one of the few instances where you may want to perform a quick sanity check to ensure that your "fire-and-forget" service is invoked (although ideally, you'd conduct an integration test with that service).

If you take a look at the DeleteTodoItem endpoint, and the DeleteAPI_CallsNotificationService_WithTaskId_AndUserId test within each test file you can see full examples of how this can be done.

We are verifying that when we call the DeleteTodoItem, on our happy path, the NotificationService.NotifyUserTaskCompleted is called with the ID of the item for deletion, and the hard-coded user ID.

As an exercise, you could create a user service which returns an ID of logged in user, and this can be used to pass the ID to the service. This can also be mocked in the test.

 // FakeItEasy
  A.CallTo(() => _fakeNotificationService.NotifyUserTaskCompleted(1,1)).MustHaveHappened(1, Times.Exactly);

// NSubstitute _notificationService.Received().NotifyUserTaskCompleted(1,1);

// Moq 
 _moqNotificationService.Verify(x => x.NotifyUserTaskCompleted(1,1)); // Defaults to Times.AtLeastOnce

// Rhino Mock
_mockNotificationService.AssertWasCalled(x=>x.NotifyUserTaskCompleted(1,1));

Conclusion

In conclusion, the versatility of mocked objects offers a myriad of applications, proving indispensable in the testing of individual units of code.

While I've covered several functionalities and validations achievable with mocks, there are more, such as method call order and negative validation.

In my view, the choice of a mocking library for a project is subjective, with no definitive right or wrong option. While some libraries may offer more convenient extensions or clearer syntax, the decision ultimately boils down to personal preference.

My hope is that this tutorial has provided you with a glimpse into the world of mocking and shed light on the syntax variances across different libraries.

As always, don't hesitate to reach out (links in bio).

This involves testing if each and every piece of code works as expected. This procedure is known as Unit Testing. Different languages provide their own frameworks for testing.

In this article, I am going to show you how to write unit tests in Java. I'll first explain what testing involves and some concepts you'll need to know. Then, I'll show a few examples to help you understand better.

For this article, I assume you are familiar with Java and the IntelliJ IDE.

Project Setup

For this project, I'll be using IntelliJ IDE. If you don't have it, follow this guide to install the IDE.

In this project, we'll be using the JUnit and Mockito libraries for testing. These are the most commonly used libraries for testing in Java. You'll understand how these libraries are used as you go through the post.

To setup JUnit, follow these steps as described in this guide:

1. From the main menu, select File > New > Project.

2. Select New Project. Specify a name for the project, I'll give it junit-testing-tutorial.

3. Select Maven as a build tool and in language, select Java.

4. From the JDK list, select the JDK you want to use in the project.

5. Click Create.

6. Open pom.xml in the root directory of your project.

7. In pom.xml, press ⌘ + N, and select Add dependency.

8. This will open a tool window, type org.junit.jupiter:junit-jupiter in the search field. Locate the necessary dependency and click Add next to it.

9. Now, click Load Maven Changes in the notification that appears in the top-right corner in the editor.

Now, to set up Mockito, add these two dependencies in your pom.xml:

<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-inline</artifactId>
    <version>5.2.0</version>
    <scope>compile</scope>
</dependency>
<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-junit-jupiter</artifactId>
    <version>5.2.0</version>
    <scope>compile</scope>
</dependency>

Note: The version may differ depending on the time you are reading this post.

To complete the setup, create a class Welcome and define your main function there.

Folder Structure and the Main Method

What is Unit Testing?

Unit Testing involves testing each and every component of your code to see if they work as expected. It isolates each individual method of your code and performs tests on it. Unit tests helps make sure that your software is working as expected before releasing it.

As a developer, you'll write unit tests as soon as you finish writing a piece of code. Now, you might ask, isn't that the job of a tester? In a way, yes, a tester is responsible for testing software. But, covering every line of code adds a lot of pressure on the tester. So, it's a best practice for developers to write tests for their own code as well.

The goal of unit testing is to make sure that any new functionality does not break the existing functionality. It also helps identify any issues or bugs earlier in the development process and helps ensure that code meets quality standards set by the organisation.

Do's and Don'ts of Unit Testing

Remember the following guidelines while writing tests for your methods:

• Do test if the expected output of a method matches the actual one.

• Do test whether the function calls made inside the method are occurring the desired number of times.

• Do not try to test code that is not a part of the method under test.

• Do not make API calls, database connections, or network requests while writing your tests.

Now, let's go over some concepts you need to know before we jump into writing tests.

Assertions

Assertions determine whether your test passes or fails. They compare the expected return value of a method with the actual one. There are a number of assertions you can make at the end of your test.

The Assertions class in JUnit consists of static methods that provide various conditions deciding whether the test passes or not. We'll see these methods as I walk you through each example.

Mocking

The class whose methods you are testing may have some external dependencies. As mentioned before, you should not try to test code that is not part of the function under test.

But in cases where your function uses an external class, it is a good practice to mock that class – that is, have mock values instead of the actual ones. We'll use the Mockito library for this purpose.

Method Stubbing

External dependencies may not be limited to just classes, but to certain methods as well. Method stubbing should be done when your function is calling an external function in its code. In this case, you make that function return the value you want instead of calling the actual method.

For instance, the method you're testing (A) is calling an external method (B) in its implementation. B makes a database query, fetching all students with marks greater than 80. Making an actual database call isn't a good practice here. So, you stub the method and make it return a dummy list of students you need for testing.

You'll understand this better with examples. There are many other concepts that are a part of testing in Java. But, for now these three are enough for you to get started.

Steps to Perform While Testing

1. Initialize the necessary parameters you'll need to perform the test.

2. Create mock objects and stub any methods if required.

3. Call the method you are testing with the parameters you initialized in Step 1.

4. Add an assertion to check the outcome of your test. This will decide if the test passes.

You'll understand these steps more with examples. Let's start with a basic test first.

How to Write the First Test

Let's write a simple function that compares two numbers. It returns 1 if the first number is greater than the second and returns -1 otherwise.

We'll put this function inside a Basics class:

public class Basics {
    public int compare(int n1, int n2) {
        if (n1 > n2) return 1;
        return -1;
    }
}

Pretty simple! Let's write the test for this class. All your tests should be located inside the test folder.

Folder Structure

Inside the test folder, create a class BasicTests where you'll write your tests for this class. The name of the class doesn't matter, but it is a good practice to segregate tests according to each class. Also, follow a similar folder structure as the one in your main code.

public class BasicTests {
    // Your tests come here
}

Unit tests are basically a set of methods you define that test each method of your class. Inside the above class, create a method compare() with a return type of void. Again, you can name the method anything you want.

@Test
public void compare() {

}

The @Test annotation indicates that this method is to be run as a test case.

Now, to test the method, you need to create the object of the above class and call the method by passing some values.

Basics basicTests = new Basics();
int value = basicTests.compare(2, 1);

Now, use the assertEquals() method of the Assertions class to check if the expected value matches the expected one.

Assertions.assertEquals(1, value);

Our test should pass, as the value returned by the method matches the expected one. To check it, run the test by right clicking the green arrow next to the test method.

Running a Test

Your test results will be shown below.

Test Results

More Test Examples

In the above test, we only tested one scenario. When there's branching in the function, you need to write tests for each condition. Let's introduce some more branching in the above function.

public int compare(int n1, int n2) {
    if (n1 > n2) return 1;
    else if (n1 < n2) return -1;
    return 0;
}

We have already tested the first branch, so let's write tests for the other two.

@Test
@DisplayName("First number is less than the second")
public void compare2() {
    Basics basicTests = new Basics();
    int value = basicTests.compare(2, 3);
    Assertions.assertEquals(-1, value);
}

The @DisplayName annotation displays the text instead of the method name below. Let's run the test.

Test Passed

For the case where the two numbers are equal:

@Test
@DisplayName("First number is equal to the second")
public void compare3() {
    Basics basicTests = new Basics();
    int value = basicTests.compare(2, 2);
    Assertions.assertEquals(0, value);
}

Sorting an Array

Now, let's write the test for the following code that sorts an array.

public void sortArray(int[] array) {
        int n = array.length;
        for (int i = 0; i < n-1; i++) {
            for (int j = 0; j < n-i-1; j++) {
                if (array[j] > array[j+1]) {
                    int temp = array[j];
                    array[j] = array[j+1];
                    array[j+1] = temp;
                }
            }
        }
    }

To write the test for this, we'll follow a similar procedure: call the method and pass an array to it. Use the assertArrayEquals() to write your assertion.

@Test
@DisplayName("Array sorted")
public void sortArray() {
    Basics basicTests = new Basics();
    int[] array = {5, 8, 3, 9, 1, 6};
    basicTests.sortArray(array);
    Assertions.assertArrayEquals(new int[]{1, 3, 5, 6, 8, 9}, array);
}

One challenge for you: write code that reverses a string and write a test case for it.

How to Create Mocks and Stubs for Testing

We have seen a few basic examples of unit tests where you made simple assertions. However, the functions you are testing may contain external dependencies like model classes and database or network connections.

Now, you can't make actual connections in your tests, as it would be very time consuming. In such cases, you mock such implementations. Let's see a few examples of mocking.

Mocking a Class

Let's have a class User with the following properties:

public class User {
    private String username;
    private String password;
    private String role;
    private List<String> posts;    
}

Click on ⌘ + N to generate getters and setters for the above properties.

Generate Options

Let's take a new class Mocking that uses the above object.

public class Mocking {
    User user;

    public void setUser(User user) {
        this.user = user;
    }
}

This class has a method that assigns certain permissions based on the user's role. It returns 1 if the permission is assigned successfully, else it returns -1.

public int assignPermission() {
        if(user.getRole().equals("admin")) {
            String username = user.getUsername();
            System.out.println("Assign special permissions for user " + username);
            return 1;
        } else {
            System.out.println("Cannot assign permission");
            return -1;
        }
    }

For demo purposes, I have only added println() statements. The actual implementation may involve setting certain properties.

In the tests file, we'll add an @ExtendWith annotation at the top since we are using Mockito. I have not shown the imports here as IntelliJ does them automatically.

@ExtendWith(MockitoExtension.class)
public class MockingTests {

}

So how do we write the test for the method? We'll need to mock the User object. You can do this by adding a @Mock annotation while declaring the object.

@Mock
User user;

You can also use the mock() method, as it's similar.

User user = mock(User.class);

Let's write the test method.

@Test
@DisplayName("Permission assigned successfully")
public void assignPermissions() {
    Mocking mocking = new Mocking();
    Assertions.assertEquals(1, mocking.assignPermission());
}

When you run the test, it throws a NullPointerException.

User Object is Null

This is because the user object hasn't been initialised yet. The method you called wasn't able to use the mocked object. For this, you'll need to call the setUser method.

mocking.setUser(user);

Now, the test gives the following error as the mocked object is initially filled with null values.

Return Value of getRole() is Null

Does this mean you need to fill actual values in the mock object? No, you just need the getRole() method to return a non-null value. For that, we'll use method stubbing.

when(user.getRole()).thenReturn("admin");

Using when()...thenReturn() tells the test to return a value when a method is called. You should stub methods only for mocked objects.

We'll do the same for the getUsername() method.

when(user.getUsername()).thenReturn("kunal");

Now, if you run the test, it will pass.

Test Passed

Method Stubbing Example

In the above example, I simply stubbed getter methods to demonstrate method stubbing. Instead of stubbing getters, you could set the role and username with a parameterised constructor or setter methods if they are available.

user.setRole("admin");
user.setUsername("kunal");

But what if the user class has a method that returns all the posts containing a certain word in them?

public List<String> getAllPostsContainingWord(String word) {
        List<String> filteredPosts = new ArrayList<>();
        for(String post: posts) {
            if(post.contains(word))
                filteredPosts.add(post);
        }
        return filteredPosts;
    }

We want this method to return all posts containing the word "awesome". If you call the actual implementation of this method, it might take a long time as the number of posts could be huge. Also, if you are mocking the User object, the posts array would be null.

In this case, you stub the method and make it return the list you want.

List<String> filteredPosts = new ArrayList<>();
filteredPosts.add("Awesome Day");
filteredPosts.add("This place is awesome");
when(user.getAllPostsContainingWord("awesome")).thenReturn(filteredPosts);

Method Stubbing in Database Queries

Let's see how to test methods that involve making database connections. First, create a class ApplicationDao that contains all the methods performing database queries.

public class ApplicationDao {  }

Define a method that fetches the user by id and returns null if the user is not found.

public User getUserById(String id) {
    // Make database query here        
}

Create another method to save a user into the database. This method throws an exception if the user object you are trying to save is null.

public void save(User user) throws Exception {
    // Make database query here
}

Our Mocking class will use these methods to implement its own functionalities. We'll implement one function that updates the name of a user.

public int updateUsername(String id, String username) throws Exception{
            ApplicationDao applicationDao = new ApplicationDao();
            User user = applicationDao.getUserById(id);
            if(user!=null)
                user.setUsername(username);
            applicationDao.save(user);
            return 1;
    }

The method implementation is pretty straightforward. First, get the user by id, change its username and save the updated user object. We'll write the test cases for this method.

There are two cases we need to test. The first is when the user is updated successfully. The second is when the update fails, that is when an exception is thrown.

Before writing the tests, create a mock of the ApplicationDao object as we do not want to make actual database connections.

@Mock
ApplicationDao applicationDao;

Let's write our first test.

@Test
    @DisplayName("User updated successfully")
    public void updateUsername() throws Exception {
        ...
    }

Create a user object for testing.

User user = new User();
user.setUsername("kunal");

Since we are calling an external method, let's stub the method so that it returns the above User object.

when(applicationDao.getUserById(Mockito.anyString())).thenReturn(user);

Pass Mockito.anyString() to the method as we want the stub to work for any string parameter. Now, add an assertion to check if the method is working correctly.

Assertions.assertEquals(1, mocking.updateUsername("3211", "allan"));

The method returns 1 on successful update, so the test passes.

Now, let's test another scenario where the method fails and throws an exception. Simulate this scenario by making the method getUserById() return null.

lenient().when(applicationDao.getUserById(Mockito.anyString())).thenReturn(null);

This value is then passed to the save() method which in turn throws an exception. In our assertion, we'll use assertThrows() method to test whether an exception was thrown. This method takes the type of the exception and a lambda expression as parameters.

Assertions.assertThrows(Exception.class, () -> {
            mocking.updateUsername("3412","allan");
        });

Since the exception is thrown, our test passes.

Tests Passed

You can find the complete code here on GitHub.

Conclusion

As a developer, writing unit tests for your code is important. It helps you identify bugs earlier in the development process.

In this post, I started by introducing Unit Testing and explained three important concepts involved in the testing process. These gave you some background before jumping into the code.

After that, I showed you, with examples, how you can test different scenarios by using the same basic techniques in testing. I also showed how to use mock classes and methods for testing complex implementations.

In a previous tutorial, we covered how to write unit tests for Python functions. While unit testing for instance methods works similarly, you may have some challenges creating and managing objects (instances of a class).

This tutorial will teach you how to use such methods for setting up and tearing down resources efficiently.

Let's begin!

Classes and Objects in Python – A Quick Review

If you're familiar with object-oriented programming, you know that classes let you group related data and behavior together. You can then use these classes as templates to create instances of the class. If a Python class is a cookie-cutter, then each instance is a cookie. 🍪

The data and behavior are described by the attributes and methods in the definition of the class, respectively. We'll look at an example to understad these better.

I know this section should have been named classes and objects explained for the impatient. 🙂 To brush up your Python OOP skills, you may check out this course on freeCodeCamp's YouTube channel.

How to Test the Instance Methods of a Python Class

Now, we'll learn how to set up unit tests for instances of Python classes. We'll write unit tests to check the functionality of the Book class shown below:

class Book:
    def __init__(self,title,author,pages,price,discount):
        self.title = title
        self.author = author
        self.pages = pages
        self.price = price
        self.discount = discount
    def get_reading_time(self):
        return f"{self.pages*1.5} minutes"
    def apply_discount(self):
        discounted_price = self.price - (self.discount*self.price)
        return f"${discounted_price}"

The Book class serves as a template or a blueprint with attributes: title, author, pages, price, and discount. get_reading_time() and apply_discount() are the instance methods that use the above attributes.

So we can create book objects from the Book class, each with their own attributes.

Illustration of book class and book objects

To test the instance methods get_reading_time() and apply_discount(), we can create two instances of the Book class inside the test methods. We can use the assertion method assertEqual() to check if the return values of the instance methods are correct.

from book import Book
import unittest

class TestBook(unittest.TestCase):
    def test_reading_time(self):
        book_1 = Book('Deep Work','Cal Newport',304,15,0.05)
        book_2 = Book('Grit','Angela Duckworth',447,16,0.15)
        self.assertEqual(book_1.get_reading_time(), f"{304*1.5} minutes")
        self.assertEqual(book_2.get_reading_time(), f"{447*1.5} minutes")
    def test_discount(self):
        book_1 = Book('Deep Work','Cal Newport',304,15,0.05)
        book_2 = Book('Grit','Angela Duckworth',447,16,0.15)
        self.assertEqual(book_1.apply_discount(),f"${15 - 15*0.05}")
        self.assertEqual(book_2.apply_discount(),f"${16 - 16*0.15}" )

if __name__=='__main__':
    unittest.main()

How to Set Up and Tear Down Resources During Unit Tests

When setting up tests for instance methods, we instantiate two book objects, then verify if the instance methods work as expected. And we need to do this for each of the methods.

But this is repetitive and suboptimal when you need to test a large number of instance methods.

In this case, it'll be more convenient if we can define a method that instantiates these objects for us before running each test. This is where the setUp() method comes into play.

How the setUp() and tearDown() Methods Work

The setUp() and tearDown() methods are typically used for the complementary tasks of allocating and deallocating resources, before and after every unit test, respectively.

• The setUp() method runs before every test, and
• The tearDown() method runs after every test.

Here, we can use the setUp() method to instantiate the book objects. Sometimes, you'll need to use the tearDown() method as well.

For example, if each test adds files to a directory or creates multiple objects in memory, you may want to free up the directory and delete the created objects after each test. We'll add the tearDown() method to verify that it runs after each test.

To understand this better, let's add explanatory print() statements, as shown in the code below:

from book import Book
import unittest
class TestBook(unittest.TestCase):
    def setUp(self):
        print("\nRunning setUp method...")
        self.book_1 = Book('Deep Work','Cal Newport',304,15,0.05)
        self.book_2 = Book('Grit','Angela Duckworth',447,16,0.15)
    def tearDown(self):
        print("Running tearDown method...")
    def test_reading_time(self):
        print("Running test_reading_time...")
        self.assertEqual(self.book_1.get_reading_time(), f"{304*1.5} minutes")
        self.assertEqual(self.book_2.get_reading_time(), f"{447*1.5} minutes")
    def test_discount(self):
        print("Running test_discount...")
        self.assertEqual(self.book_1.apply_discount(),f"${15 - 15*0.05}")
        self.assertEqual(self.book_2.apply_discount(),f"${16 - 16*0.15}" )
if __name__=='__main__':
    unittest.main()

Now, run the test_book module. Here's the output:

Output
Running setUp method...
Running test_discount...
Running tearDown method...
.
Running setUp method...
Running test_reading_time...
Running tearDown method...
.
----------------------------------------------------------------------
Ran 2 tests in 0.003s
OK

How to Use the setUpClass() and tearDownClass() Methods

In addition to the above methods, you can also use the class methods: setUpClass() and tearDownClass().

In Python, class methods bind to a class and not to a particular instance. To define a method as a class method, you can use the @classmethod decorator.

So when should we use these class methods?

Instantiating objects, as in the above example, is a simple task and not computationally expensive. But you may sometimes have tasks that are too expensive to be performed before every test: for instance, spinning up an in-memory database.

If all subsequent tests in the test class only read in some data from the database, we can use the setUpClass() class method to spin up the database and the tearDownClass() class method to tear down the database after all tests have run.

Putting it all together:

• The setUpClass() class method is executed before any of the tests are run.
• The tearDownClass() class method is executed after all the tests have run.
• The setUp() and tearDown() methods are executed before and after each test, respectively.

Let’s add the setUpClass() and tearDownClass() class methods to the TestBook class.

from book import Book
import unittest
class TestBook(unittest.TestCase):
    @classmethod
    def setUpClass(cls):
        print("\nsetUpClass method: Runs before all tests...")
    def setUp(self):
        print("\nRunning setUp method...")
        self.book_1 = Book('Deep Work','Cal Newport',304,15,0.05)
        self.book_2 = Book('Grit','Angela Duckworth',447,16,0.15)
    def tearDown(self):
        print("Running tearDown method...")
    def test_reading_time(self):
        print("Running test_reading_time...")
        self.assertEqual(self.book_1.get_reading_time(), f"{304*1.5} minutes")
        self.assertEqual(self.book_2.get_reading_time(), f"{447*1.5} minutes")
    def test_discount(self):
        print("Running test_discount...")
        self.assertEqual(self.book_1.apply_discount(),f"${15 - 15*0.05}")
        self.assertEqual(self.book_2.apply_discount(),f"${16 - 16*0.15}" )
    @classmethod
    def tearDownClass(cls):
        print("\ntearDownClass method: Runs after all tests...")

if __name__=='__main__':
    unittest.main()

Now, rerun test_book.py.

From the output below, we see that the setUpClass() and tearDownClass() methods run before and after all the tests, respectively.

Output
setUpClass method: Runs before all tests...
Running setUp method...
Running test_discount...
Running tearDown method...
.
Running setUp method...
Running test_reading_time...
Running tearDown method...
.
tearDownClass method: Runs after all tests...
----------------------------------------------------------------------
Ran 2 tests in 0.010s
OK

Conclusion

I hope this tutorial helped you learn how to set up unit tests for instance methods in Python.

If you're interested in learning more about the need for unit testing with a focus on doing it for Python functions, consider reading the article How to Write Unit Tests for Python Functions.

Happy coding!

Now, you can’t do that just by going through the website yourself – you need to check if each unit of your code is working as you want. For that, you need to write unit tests. And they can be quite a hassle when you actually get down to writing them.

So, in this post, I am going to show you how you can get started with writing unit tests in React. I will explain the process through several examples to help you understand better.

For this post, I assume you have a basic knowledge of React. If not, then head over to the docs to get started.

How Is a Test Structured?

Testing involves checking if your code is functioning as it's supposed to by comparing the expected output with the actual output.

What to Test

In general, your tests should cover the following aspects of your code:

1. If a component renders with or without props

2. How a component renders with state changes

3. How a component reacts to user interactions

What Not to Test

Testing most of your code is important, but here are some things you do not need to test:

1. Actual Implementation: You do not need to test the actual implementation of a functionality. Just test if the component is behaving correctly.
   Let’s say you want to sort an array on the click of a button. There’s no need to test the actual sorting logic. You only test if the function was called and if the state changes are rendering correctly.

2. Third Party libraries: If you are using any third party libraries like Material UI, no need to test those – they should already be tried and tested.

This might seem a little complicated at the moment, but you should understand better through examples.

Any test in React, no matter how complicated, follows this structure:

1. Render the component

2. Get an element from the component and simulate any user interactions

3. Write an assertion.

How to Set Up Our Project

First, create the app with create-react-app. We’ll be using Jest and React Testing Library. Both of them come pre - installed with create-react-app. You can see what it looks like here:

"dependencies": {
    "@testing-library/jest-dom": "^5.16.5",
    "@testing-library/react": "^13.4.0",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "react-scripts": "5.0.1",
    "web-vitals": "^2.1.4"
},

As you can see, Jest is not visible here. But, if you go to the node_modules folder, you will see Jest there. So, no need to install it separately.

Also, make sure you have the following lines in your setupTests.js file:

import '@testing-library/jest-dom';
import '@testing-library/jest-dom/extend-expect';

Also, in your package.json file, modify your scripts like this:

"scripts": {
    "start": "react-scripts start",
    "build": "react-scripts build",
    "test": "react-scripts test --watchAll --coverage",
    "eject": "react-scripts eject"
},

This will run your tests in watch mode and also show you the coverage (that is, the portion of the code covered by your tests). You can also define the coverage threshold by adding another property jest. For now, keep the threshold at 80%.

"jest": {
    "coverageThreshold": {
        "global": {
            "lines": 80
        }
    }
}

That’s it, now you are ready to start testing. Let’s first start with a basic test.

How to Write Your First Test for a React App

Let’s write a test for the following component:

const FirstTest = () => {
  return (
    <div>
        <h2> First test </h2>
    </div>
  )
}

Here, we just need to test if the h2 element renders. Now, where should we write the tests? We can write them inside a __tests__ folder anywhere in the src folder. The test file just needs to have a .test.js/jsx extension and the test runner will pick it up.

This is how the test looks in our FirstTest.test.jsx file:

import { render, screen } from '@testing-library/react'
import FirstTest from '../components/FirstTest';

test("Example 1 renders successfully", () => {
    render(<FirstTest/>);

    const element = screen.getByText(/first test/i);

    expect(element).toBeInTheDocument();
})

First, import the required methods. The test() method contains an individual test. It takes the name of the test and a callback function as the two arguments.

Now, following the structure mentioned above, render the component you're testing using the render method. Then, use the screen object to make a query for an element. In this case, it’s the h2 element. Our query gets an element containing text that matches the regex /first test/i (i means ignore case).

Lastly, make the assertion using the expect method. We expect the element to be in the document and it is, so the test passes.

There are lots of other assertions you can make in your tests. You can read more about them here. Also, you can find a list of ways to query an element here. We’ll use some of them in our further examples.

How to Test With Mock Data in React

Here, we have a component with a prop data that displays a list of items. Let’s assume this data comes from the backend and your component is displaying this data.

import React from 'react'

const TestWithMockData = ({data}) => {
  return (
    <div>
        <ul>
            {data.map(item => (
                <li key={item.id}>
                    {item.id}
                    {item.first_name},
                    {item.last_name},
                    {item.email}

                </li>
            ))}
        </ul>
    </div>
  )
}

export default TestWithMockData

While writing tests for a component with props, you need to pass some mock data while rendering this component that pertains to your functionality. Here, one object in our data contains four fields, so we pass some mock data here.

const mockData = [
    {
        "id": 1,
        "first_name": "Fletcher",
        "last_name": "McVanamy",
        "email": "mmcvanamy0@e-recht24.de",
        "age": 30
      }, {
        "id": 2,
        "first_name": "Clarice",
        "last_name": "Harrild",
        "email": "charrild1@dion.ne.jp",
        "age": 35
      }, 
]

Note that the actual data could contain thousands of records, but the mock data only needs to be relevant to what you want to test. Now, let’s write the test and check if the list renders.

test("List renders successfully", () => {
    render(<TestWithMockData data={mockData} />)
    expect(screen.getByText(/fletcher/i)).toBeInTheDocument();
})

How to Test With Mock Data Covering All Branches in React

Let’s introduce some branching in the above component. We’ll have another prop, displayUnorderedList, that determines whether to display an ordered or unordered list. We’ll also render Senior for age > 50 and Not Senior otherwise.

import React from 'react'

const TestWithMockData = ({data, displayUnorderedList, handleClick}) => {
  return (
    <div>
        {displayUnorderedList ? 
            <ul>
                {data.map(item => (
                    <li key={item.id}>
                        {item.id}
                        {item.first_name},
                        {item.last_name},
                        <a onClick={() => {
                            console.log("email link clicked")
                            handleClick()
                        }}>{item.email}</a>

                        {item.age > 50 ? 'Senior' : 'Not senior'}

                    </li>
                ))}
            </ul>
        : 
            <ol>
                {data.map(item => (
                    <li key={item.id}>
                        Last name: {item.last_name}
                    </li>
                ))}
            </ol>
        }
    </div>
  )
}

export default TestWithMockData

Here's the coverage report so far:

Failed Test: Unable to find the element

You can see that Line 9 (that is, the unordered list part) is not covered by our existing tests. And our previous test has also failed since it is unable to find fletcher in the component.

Why is this so? In our previous test, we have not passed the displayUnorderedList prop to the component so it is null. So, the component renders the ordered list and it does not contain the first_name.

So, let’s write another test covering the ordered list part.

test("Ordered list renders", () => {
    render(<TestWithMockData data={mockData} displayUnorderedList={false} />)

    expect(screen.getByText(/McVanamy/i)).toBeInTheDocument()
})

Here, pass the prop’s value as false to render the ordered list. Also, add the displayUnorderedList prop to the failing test and pass the value true.

Now, all our tests pass with 100% coverage.

Uncovered Branch

One line is still not covered by the test cases, which is the branching logic for age. So, add another record to the mock data that has an age greater than 50.

{
    "id": 3,
    "first_name": "Amby",
    "last_name": "Emmer",
    "email": "aemmer2@buzzfeed.com",
    "age": 67
}

Now, all our tests should pass with 100% coverage.

How to Test User Interactions in React

The most important part of testing any UI app is testing its behaviour with various user interactions. Almost every functionality in a UI app involves user interactions.

You can use the user-event library to simulate user interactions. It has methods for simulating various user events such as click, type, hover, and so on.

First, we need to install the library:

npm install --save-dev @testing-library/user-event

We can use this library to simulate user events. In our examples, we’ll interact with different elements, mostly input and button elements.

How to Test a Function Call on Click of an Element

In our above component, we need toTestWithMockData, make the email field clickable and call a function handleClick on it. This will be passed as props to the component. There, replace {item.email} with:

<a onClick={() => {
    console.log("email link clicked")
    handleClick()
}}>{item.email}</a>

Now, our test coverage takes a hit. To cover this scenario, write the following test:

test("Email link click handler called", async () => {
    const mockHandleClick = jest.fn();
    render(<TestWithMockData 
                data={mockData} 
                displayUnorderedList={true}
                handleClick = {mockHandleClick}
          />)
    await userEvent.click(screen.getByText(/mmcvanamy0@e-recht24.de/i));
    expect(mockHandleClick).toHaveBeenCalled();
})

First, create the mock of the handleClick function using jest.fn(). We do not need the actual implementation of the method, as we only want to test the behaviour of the component. So, we create an empty mock and pass the same as props. Read more about mocking functions here.

Now, query the <a> element by text (any email from the mock data). Use the click() method to simulate a click event. Use await as simulating a user event is an asynchronous operation.

Write an assertion in the end to check if the method was called. The method was called, so our test passes with 100% coverage.

How to Query Input Fields and Buttons

So far, we have used only one method of querying elements – getByText(). Now, let’s see how you can query input fields and buttons.

<input placeholder='Enter name'/>
<button> Submit </button>

To query these elements, you can do the following:

const inputElement = screen.getByRole('textbox')

getByRole finds an element by the given role. In this case, the textbox role means the input element.

How is role determined? Each element has a defined role, so you do not need to specify an explicit role attribute. You can see a list of roles for different elements here. Whatever element you want, just do getByRole and refer to the list.

For button, the default role is ‘button’ as you can see here:

const button = screen.getByRole('button')

What if we add another input element, <input placeholder=’Enter description’/>? The test runner will now throw an error saying that there are two elements with the same role. What should we do in such a scenario? Use another query getByPlaceholderText().

const nameInput = screen.getByPlaceholderText(/enter name/i);
const descrInput = screen.getByPlaceholderText(/enter description/i);

You can also use getByLabelText() if your input has a label.

<label htmlFor='password'> Enter password</label>
<input type='password' id='password'/>

const passwordInput = screen.getByLabelText(/enter password/i);

For querying buttons, we can do screen.getByRole('button').

<button> Submit </button>
<button> Apply</button>

Since we have two buttons here, just doing getByRole will throw an error. So, we use a name option.

const submitButton = screen.getByRole('button', { name: /submit/i });
const applyButton = screen.getByRole('button', { name: /apply/i });

The name option can contain the label of a form element, text of a button, or the value of the aria-label attribute of any element. We can also do getByText() for a button.

const submitButton = screen.getByText(/submit/i);

How to Test State Updates in React

We have seen how to query form elements like input and button. Now, let’s simulate some user interactions and test state updates. What do I mean by testing state updates?

State updates cause a component to re-render. So, when your functionality performs a state update, you should test how the component is behaving due to the state change.

First, let’s take a simple example where we set the state as soon as the component is loaded – that is, in the useEffect block.

const TestingStateChange = () => {
    const [loaded, setLoaded] = useState(false)
    useEffect(() => {
        setLoaded(true)
    }, [])
  return (
    <div>
        {loaded && <h3> Page Loaded </h3>}
    </div>
  )
}

Here, your entire component, starting from the useEffect statement to the end, is uncovered. When you write the following test, not only does the HTML part get covered but also the useEffect part where you set the state.

test("Testing page load", () => {
    render(<TestingStateChange/>)
    expect(screen.getByText(/page loaded/i)).toBeInTheDocument();
})

This is how you test state updates. You test whether the component behaves as you expect with a state change.

How to Test a State Change on Click of a Button

Let’s have a button and a text that toggles on the click of the button.

const [toggleTextVisible, setToggleTextVisible] = useState(false)`

{toggleTextVisible && <p> Text visible </p> }

<button onClick={() => { setToggleTextVisible(!toggleTextVisible) }}> 
    Toggle text 
</button>

We’ll write the test for this:

test("Toggle text visible", async () => {
    render(<TestingStateChange/>);
    await userEvent.click(screen.getByText(/toggle text/i));
    expect(screen.getByText(/text visible/i)).toBeInTheDocument();
})

With userEvent, we have simulated the click of a button and asserted if the text is visible.

Now, let’s test another scenario where we check if the above button is disabled on the click of another button.

const [btnDisabled, setBtnDisabled] = useState(false);

Add a disabled={btnDisabled} attribute to the above button and create another button that controls its value.

<button onClick={() => { setBtnDisabled(!btnDisabled) }}> 
      Toggle button disabled 
</button>

Use the toBeDisabled() method to test if the button is disabled.

test("Button disabled on click", async () => {
    render(<TestingStateChange/>)
    await userEvent.click(screen.getByText(/toggle button disabled/i));
    expect(screen.getByText(/toggle text/i)).toBeDisabled();
})

How to Test if an Element Was Added to a List

Let’s perform another assertion. Here, we’ll check if an element was added to a list. We’ll have some data and create a state with the data as the initial value. We'll display it while also having a button to add an element to it.

const [elements, setElements] = useState(data);

<h3> List </h3>
{elements.map(item => (
    <div key= {item.id}>
       {item.id}: { item.name }
    </div>
))}
<button onClick={() => {
    setElements([...elements, {
        id: 4,
        name: 'abhinav'
    }])
}}> Add to list </button>

Add an attribute data-testid='record' to each record to help query the element. Let’s write the test for this:

test("Element added to the list", async () => {
    render(<TestingStateChange/>)
    expect(screen.getAllByTestId('record').length).toBe(3);

    await userEvent.click(screen.getByText(/add to list/i));
    expect(screen.getAllByTestId('record').length).toBe(4);
})

To get multiple elements with the same query, use the getAllBy… method. In this case, there are multiple elements with the test-id record, so using the getAllByTestId() method gets a list of all such elements.

Here, we have checked the length of the list. We can add another assertion to check if the new element is visible.

expect(screen.getByText(/abhinav/i)).toBeInTheDocument();

How to Test if an Element Was Removed From a List

Now, let’s add another button that removes an element from the list.

<button onClick={() => {
    setElements(elements.filter(item => item.id != 2))
}}> Remove from list </button>

The test for this:

test("Element removed from list", async () => {
    render(<TestingStateChange/>)
    await userEvent.click(screen.getByText(/remove from list/i));
    expect(screen.getAllByTestId('record').length).toBe(2);
})

Here, we test whether the length of the list was reduced. All our tests pass with 100% coverage.

Coverage Report for Testing State Change: Tests Passed

How to Test API Calls in React

API calls are an important part of any UI application. Let’s understand how to test an API call.

In this example, we have a file data.json that has some data. We’ll make an API call to fetch this data.

For demonstration, we’ll save this file on the local server only (inside the public folder), but the procedure remains the same when fetching a file from a remote server.

We’ll use fetch to make the API call.

fetch("http://localhost:3000/data.json")
  .then(res => {
      return res.json();
  })
  .then(data => {
      // Store the data in state
  })

Now, let’s have a state to store the data and render it.

const [data, setData] = useState([])

<div>
    {data.map(item => (
        <div>
            {item.name}
        </div>
    ))}
</div>

How do we write the test for this? One way is to mock the fetch method and provide our own mock implementation. But what if there are multiple Fetch API calls in the component? You cannot have the same mock implementation for everyone.

So, we put the fetch call in a separate function and have a mock implementation of that function. We put our API call in a FetchData method that returns the promise returned by fetch.

We put the method in a separate Services.js file and export it from there.

export const FetchData = () => {
    return fetch("http://localhost:3000/data.json")
        .then(res => {
            return res.json();
        }) 
}

Now, when we call this method inside our component, it looks like this:

const [data, setData] = useState([])

useEffect(() => {
    FetchData().then(data => {
        setData(data);
    })
})

return (
  <div>
      {data.map(item => (
          <div>
              {item.name}
          </div>
      ))}
  </div>
)

Now, let’s write the test for this. The main thing is to mock the FetchData method. First, import all methods from Services.js as a module.

import * as services from '../utils/Services'

Let’s mock our function using jest.spyOn(). The method takes two arguments, the object and the method name as a string.

const mockFetchData = jest.spyOn(services, 'FetchData')
        .mockImplementation(async () => {
            return [{
                name: 'kunal'
            }];
        })

spyOn creates an empty mock of the method. Now, we provide our mock implementation where we return some mock data. This will be called when our component renders.

render(<TestingAPICalls/>)
expect(mockFetchData).toHaveBeenCalled();

We use toHaveBeenCalled() to test if the method was called. It was – so the test passes. Now, to test the behaviour of our component, let’s test if the name was rendered.

expect(screen.getByText(/kunal/i)).toBeInTheDocument();

In this case, the test fails as it is unable to find the element. Why is this so?

Failed Test: Unable to find the element

Since API calls and state updates are asynchronous, the text hasn’t been rendered yet. To test asynchronous behaviour, wrap the query in a waitFor() block.

await waitFor(() => {
    expect(screen.getByText(/kunal/i)).toBeInTheDocument();
})

waitFor does exactly what the name suggests. It waits for the asynchronous behaviour to finish before making the query. Now, our test passes with 100% coverage.

100% Coverage for Testing API Calls

You can find the complete code on GitHub.

Conclusion

Phew! That was a long one. But it needed to be. I have explained, through basic examples, how you can start writing tests in React.

This article started from a basic test with a simple assertion and explained how to use mock data to serve the purpose of your test.

I also explained how to simulate user interactions, how to test a component’s behaviour on state updates, and lastly how to test API calls. Hopefully, all these examples help you write tests for your upcoming project.

If you are unable to understand the content or find the explanation unsatisfactory, please let me know. New ideas are always appreciated! Feel free to DM me on LinkedIn if you want to discuss anything. Until then, Goodbye!

So let's get started.

What We'll Cover:

1. Why Do You Need to Write Unit Tests?
2. What is the React Testing Library?
3. What Not to Test with the Testing Library
4. How to Setup a React Project with Vite
5. How to Set Up the Testing Library and Jest in a React Project
6. How to Create the UI for Testing
7. How to Write Unit Test Cases
8. Let's Write Some More Tests
9. Conclusion

If you want to learn the React Testing Library in depth from scratch, you can check out my MERN stack course.

Why Do You Need to Write Unit Tests?

You might think that you don't need to write so many unit test cases and that it's a waste of time. Perhaps you can manually test the application instead.

Well, you're right – you can certainly do that. But as the application grows, it might be difficult to test all the scenarios in the application and you might miss something. Even a small change might break the application if all the major functionality is not tested properly.

That's why I recommend writing unit test cases covering all those scenarios which you're manually going through as a user.

So by executing just a single command you will be able to know if something is broken in your application or if some test is failing.

What is the React Testing Library?

The React Testing Library has a set of packages that help you test UI components in a user-centric way. This means it tests based on how the user interacts with the various elements displayed on the page.

So what happens is when the user clicks any button or types in any of the input textboxes, that interaction is tested using this testing library.

So instead of the user doing this testing manually (which takes a lot of time, and the user might miss testing certain scenarios when the application grows), the testing is done by writing unit test cases and executing them by just a single command.

What Not to Test with the Testing Library

Testing Library encourages you to avoid testing implementation details like the internals of a component you're testing.

The guiding principles of this library emphasize a focus on tests that closely resemble how users interact with your web pages.

You may want to avoid testing the following implementation details:

• Internal state of a component
• Internal methods of a component
• Lifecycle methods of a component
• Child components

So if you have experience with enzyme testing, you might be checking the value of state once you click any button or you might be checking the prop value If something changes.

But these types of checks are not necessary for testing with the React testing library. Instead, in the React testing library, you check the behavior of the DOM when the user clicks on a button or submits a form and so on.

How to Setup a React Project with Vite

To set up our app that we'll test, we'll be using Vite. It's a popular and faster alternative to create-react-app.

We'll use Vite because create-react-app becomes slow when the application grows and takes a lot of time to refresh the page when we make any changes in the application code. Also, by default, it also adds a lot of extra packages which we rarely need.

Vite just rebuilds the things we changed, instead of rebuilding the entire application which saves a lot of time during development.

Keep in mind that Vite requires Node.js version 14.18+, so make sure to install a Node version greater than or equal to 14.18.

The easiest and simplest way to install and switch Node.js versions is to use nvm.

Even if you're using create-react-app, all the tests you will learn in this tutorial should run exactly the same without any errors.

To create a new Vite project with React, execute the npm init vite command from the terminal.

It will ask you the project name, framework, and variant.

• For project name, you can enter testing-library-demo or any name of your choice.
• For framework, select React from the list of options
• For variant, select JavaScript from the list of options

Create a new React project using Vite

Once the project is created, you can open that project in your favorite IDE.

The project folder structure will look like this:

Folder structure of React Vite project

Now, execute the yarn or npm install command to install all the packages from the package.json file.

Once all the packages are installed, you can execute the yarn run dev or npm run dev command to start the created React application.

Running a React app

Now, if you access the displayed URL http://127.0.0.1:5173/ you will be able to see the default React application created using Vite.

Default React page rendered using Vite

So let's see how we can set up the Testing Library in our Vite project.

How to Set Up the Testing Library and Jest in a React Project

You can't just use the testing library alone – you also need to install Jest. It exposes an extensively used global expect function and other things which help you make assertions in your test cases.

To set up Testing library and Jest, you need to install the Jest and Testing Library packages as dev dependencies.

So execute the following command from the testing-library-demo folder:

yarn add @testing-library/jest-dom@5.16.5 @testing-library/react@13.4.0 @testing-library/user-event@14.4.3 jest@29.3.1 jest-environment-jsdom@29.3.1 vitest@0.25.3 --dev

or with npm:

npm install @testing-library/jest-dom@5.16.5 @testing-library/react@13.4.0 @testing-library/user-event@14.4.3 jest@29.3.1 jest-environment-jsdom@29.3.1 vitest@0.25.3 --save-dev

I'm mentioning versions here for each package which are the latest versions at the time of writing this tutorial. So even if there is a newer breaking version release that happens for any of the packages in the future, your code will not break.

Here, we're installing the jest-environment-jsdom library because we will be running tests in the node environment. But we're testing browser interactions through the DOM – so to inform Jest about that, we need to add this library.

The @testing-library/jest-dom library is required because it contains assertions like toBeInTheDocument, toHaveBeenCalled, and others which make it easy to test for DOM elements, which you will see later in this tutorial.

We have also added the vitest package which is only required when you're using Vite for the application.

You don't need it if you're using create-react-app or your own webpack configuration.

Now that we have installed the required packages, let's add a script in the package.json file to run the tests.

Open the package.json file and add the test script inside it like this:

"test": "vitest"

Your package.json file will look like this now:

Package.json file preview

If you're not using vite for creating the React app, then you will be using the following test script:

"test": "jest --watch"

Now, create a new file in the root of your project (testing-library-demo) with the name setupTests.js and add the following code inside it:

import "@testing-library/jest-dom";

Now, open the vite.config.js file and add a new test object as shown in the below screenshot:

vite.config.js file configuration

How to Create the UI for Testing

Before writing tests, we need to have some components to test.

So let's create a simple registration page with some checkboxes, input fields, select dropdown, and buttons so we can write test cases for it.

We will use react-bootstrap to create the UI elements so we don't have to write all the CSS from scratch.

Install bootstrap and react-bootstrap by executing the following command from the terminal:

yarn add bootstrap@5.2.3 react-bootstrap@2.6.0 react-select@5.6.1

or with npm:

npm install bootstrap@5.2.3 react-bootstrap@2.6.0 react-select@5.6.1

Bootstrap provides a base CSS which we need for the UI to look nice, so we're also installing Bootstrap along with react-bootstrap.

Once installed, open src/main.jsx and add an import for the Bootstrap CSS file before any of your other CSS files as shown below:

import "bootstrap/dist/css/bootstrap.min.css";

Your src/main.jsx file will look like this now:

bootstrap css imported

We don't need the index.css and App.css files so you can delete them.

Now, create a components folder inside the src folder and create a register folder inside the components folder. Inside the register folder, create Register.jsx and register.css files.

So your Register.js file path will be src/components/register/Register.js.

Add the content from this repo in the Register.jsx file and inside register.css file add contents from this repo.

Now, open the App.jsx file and add the following contents inside it:

import Register from "./components/Register";

function App() {
  return <Register />;
}

export default App;

Now, if you run the application by executing the yarn run dev or npm run dev command, you will see the following screen:

Registration page

This tutorial is focused on the testing library, so I'm not going to explain the code from the Register.js file as it's basic React code. But If you're not familiar with React hooks, you can check out this article to understand it better.

Also, instead of managing the state and onChange handler yourself, you can use the very popular react-hook-form library.

It also allows you to add validations to your code without writing much code. Check out this article if you want to learn about it in detail.

Now, we're all set to write unit test cases, so let's get started.

How to Write Unit Test Cases

Before writing test cases, you should be aware of the different queries which you can make to access elements on the page.

The Testing Library provides a set of queries which you can see in the below screenshot:

Screenshot showing getBy, queryBy, findBy, getAllBy, queryAllBy, and findAllBy queries. (Source)

To summarise:

• To select a single DOM element, you can use the getBy, findBy, or queryBy query
• To select multiple DOM elements, you can use the getAllBy, findAllBy or queryAllBy query
• getBy and findBy return an error if there is no match or more than one match
• queryBy returns null if there is no match and returns an error if there is more than one match
• findBy works well with asynchronous code but not with getBy and queryBy
• getAllBy returns an error if there is no match and returns an array of matches for one or more than one match
• findAllBy returns an error if there is no match and returns an array of matches for one or more than one match
• queryAllBy returns an empty array for no match and returns an array of matches for one or more than one match

So if you don't want your test to fail if the element is not displayed on the UI, then always use queryBy or queryAllBy.

In other words, only use the queryBy or queryAllBy queries for asserting that an element cannot be found or is hidden.

Now that you're familiar with query methods, let's start writing test cases for the Register component.

Create a new register.test.jsx file in the src/components/register folder with the following content inside it:

import { render, screen } from "@testing-library/react";
import Register from "./Register";

describe("Register component", () => {
  it("should render Register component correctly", () => {
    render(<Register />);
    const element = screen.getByRole("heading");
    expect(element).toBeInTheDocument();
  });
});

Note that we're using Vite so the filename has to end with the .jsx extension even for test files. If you're not using vite then you can end the filename with the .js extension.

Now, if you execute the npm run test or yarn run test command you will see that the test passes.

one test passed

In the above code, we're first rendering the Register component using the render method provided by the testing library.

As we have an h1 element with Register text in the Register component, we're using the screen.getByRole method to get the DOM element of the role heading.

If you don't know what role to use in the getByRole method, then you can use some random name and the testing library will show you all the available roles for each DOM element for that component as shown below:

Seeing the DOM structure of UI elements

Once we get that element using the getByRole method, then we're making an assertion to check if that element exists in the DOM using:

expect(element).toBeInTheDocument();

You can see a list of all available getBy,findBy or queryBy methods by adding a dot after screen like this:

Methods provided by screen object

Now, we have added one test to check if the Register component is getting rendered correctly or not.

Let's write some more tests.

If you run the application by running the yarn dev command, you will see that, once you click on the Register button without filling out all the details, you get an error message as shown below.

Error message display on submitting form without entering data

So now, we need to test the same by writing a test case.

For that, we can use userEvent from the @testing-library/user-event package which we've already installed.

Now, add a new test in your register.test.jsx file as shown below:

it("should show error message when all the fields are not entered", () => {
    render(<Register />);
    const buttonElement = screen.getByRole("button");
    userEvent.click(buttonElement);
});

Your register.test.jsx file will look like this:

New test added for testing error message display

So we're triggering the click event for the Register button in the above code.

Now, we need to find the element with the error message so we can add assertions for it in the test.

The error message is actually an Alert component from react-bootstrap which is not visible initially. It's only displayed when we submit the form without filling in all the data.

In such a case, we can call the screen.debug method to see the structure of the DOM at that moment when we trigger the click event.

So change the test case as shown below:

it("should show error message when all the fields are not entered", async () => {
    render(<Register />);
    const buttonElement = screen.getByRole("button");
    userEvent.click(buttonElement);
    screen.debug();
});

Note that we have added screen.debug at the end of the test.

Now, if you run the yarn run test or npm run test, you will see the following DOM structure:

DOM structure when after submitting the Form

As you can see from the screenshot, you directly see the name input label inside the form tag after the Register heading.

So we're not able to see the error message even if we have triggered the click event for the button.

This is because it takes some time to execute the validation code from the handleFormSubmit method. Before that we're only using the screen.debug method so we don't see the error message.

So to fix this, we can wait using async/await.

So declare the test function as async and before the userEvent.click(buttonElement) add an await keyword like this:

Added async/await

Now, if you check the console, you will be able to see the text All the fields are required. inside a div with the role alert.

Error message getting displayed in DOM structure

So we can use it in our assertion like this:

const alertElement = screen.getByRole("alert");
expect(alertElement).toBeInTheDocument();

And now, you can see that the second test is also successful.

test passed

Some points to note:

• Always remember to remove the screen.debug statement once you're done with your assertions, and never keep it in your code.
• Always add an await keyword before triggering any event using userEvent as you may not know when the action will be completed.

Let's Write Some More Tests

Now that we're done with adding these two tests, we can add one more test to check if there is no error when the page is loaded like this:

it("should not show any error message when the component is loaded", () => {
    render(<Register />);
    const alertElement = screen.getByRole("alert");
    expect(alertElement).not.toBeInTheDocument();
});

Here, instead of using this:

expect(alertElement).toBeInTheDocument();

we're using this:

expect(alertElement).not.toBeInTheDocument();

Because we want the alert element to be not present on the component load.

But if you check the console, you will see that the test is failing.

Failed test when using getByRole

So, the test is not failing because of our assertion. Rather, it's failing because it can't find an element with role alert on page load which is expected, as there will not be any error on page load.

But how we can make the test pass?

If you remember from the list of queries in the screenshot shown before:

Screenshot showing getBy, queryBy, findBy, getAllBy, queryAllBy, and findAllBy queries.

The getBy method throws an error if it does not find the matching element. So instead of using getBy we need to use queryBy. It does the same thing but it does not throw an error when there is no matching element.

So let's modify our test case to the below code:

it("should not show any error message when the component is loaded", async () => {
    render(<Register />);
    const alertElement = screen.queryByRole("alert");
    expect(alertElement).not.toBeInTheDocument();
});

Now, if you check the console, you will see that the test passes successfully.

Passed test when using queryByRole

Now, let's write a test for successful registration when we fill out all the required fields.

it("should show success message when the registration is successful.", async () => {
    render(<Register />);
    const buttonElement = screen.getByRole("button");
    await userEvent.click(buttonElement);
    const alertElement = screen.getByRole("alert");
    expect(alertElement).toBeInTheDocument();
});

Now if you see the console, you will see that the test passes successfully.

Let's add a subheading to the registration page and see what happens when we run the tests again.

Add the following heading inside the Form tag in the Register.jsx file:

<h6 className="subtitle">
   Please enter your details below to register yourself.
</h6>

So your code will now look like this:

Added new subheading

Now, if you run the tests again, you will see that one test fails:

Failed test due to multiple headings on the page

The test failed because in the first test we're finding the Register heading text as shown below:

screen.getByRole("heading")

And as you know, getBy returns an error when you have more than one match.

Here, we have two headings on the Register component so the test failed.

So how can we fix it?

To fix it we need to identify how to accurately select elements while writing tests.

I have seen many developers changing the HTML structure by adding some testid so they can get the test passed like this:

it("should render Register component correctly", () => {
    render(<Register />);
    const element = screen.getByTestId("title");
    expect(element).toBeInTheDocument();
});

Assuming you added an extra data-testid attribute to your JSX like this:

<h2 className="title" data-testid="title">
     Register
</h2>

This will work and make your all tests pass. But this is not the correct way.

Just to make your test pass, you should not change your JSX by adding some extra testid or class.

Instead, you should always try to use methods provided by screen to make an accurate selection of DOM elements.

So now the question is how to make an accurate selection.

The getByRole method accepts optional options which you can use like this:

const element = screen.getByRole("heading", { level: 2 });

As our main Register heading is a h2 heading, we specifically said to select level 2 heading.

Now, if you update the first test case, you will see that all the tests are passing.

Test passed by adding more specific query for heading

Now, let's add another test for testing the subheading.

As the subheading is of level 6, you can query it like this:

const element = screen.getByRole("heading", { level: 6 });

This will work, but there is another way we can target that element.

For that, you can install the testing playground Chrome browser extension.

Once it's installed, follow the below steps:

• open your Chrome dev tools using Ctrl + Alt + I or Cmd + Option + I (Mac)
• select the Testing Playground tab
• Click the cursor pointer and select the subheading of the Register component as shown below:

Testing Playground extension demo

As you can see, you will get the accurate DOM element query which you can use in your test like this:

screen.getByRole('heading', {
  name: /please enter your details below to register yourself\./i
})

So you can write your test like this:

 it("should test for presence of subheading in the component", () => {
    render(<Register />);
    const element = screen.getByRole("heading", {
      name: /please enter your details below to register yourself\./i
    });
    expect(element).toBeInTheDocument();
 });

Test result

Writing a test case for subheading is not necessary, because it does not affect the component behavior even if you don't test that. But just to show you how your tests will break for multiple elements, I have added that element on the UI along with its test case.

The Testing Playground Chrome extension is really useful to find out the exact matching query for any of the UI elements.

So instead of using the screen.debug method to see the DOM structure, you can use this Chrome extension to find out the role and other information for all the displayed elements as can be seen below:

Finding out specific query using testing playground

As you can see, you can get any element by role, by placeholder text, or by label text with the methods provided by screen.

Now that you're aware of the more specific query selectors, let's update other test cases to use the specific selectors.

Wherever we're using just screen.getByRole("button"), replace it with the following:

screen.getByRole("button", {
  name: /register/i
})

So now, if later someone adds another button in the same component, your test will not fail.

Your final register.test.jsx file will look like this:

import { render, screen } from "@testing-library/react";
import userEvent from "@testing-library/user-event";
import Register from "./Register";

describe("Register component", () => {
  it("should render Register component correctly", () => {
    render(<Register />);
    const element = screen.getByRole("heading", {
      level: 2
    });
    expect(element).toBeInTheDocument();
  });

  it("should test for presence of subheading in the component", () => {
    render(<Register />);
    const element = screen.getByRole("heading", {
      name: /please enter your details below to register yourself\./i
    });
    expect(element).toBeInTheDocument();
  });

  it("should show error message when all the fields are not entered", async () => {
    render(<Register />);
    const buttonElement = screen.getByRole("button", {
      name: /register/i
    });
    await userEvent.click(buttonElement);
    const alertElement = screen.getByRole("alert");
    expect(alertElement).toBeInTheDocument();
  });

  it("should not show any error message when the component is loaded", () => {
    render(<Register />);
    const alertElement = screen.queryByRole("alert");
    expect(alertElement).not.toBeInTheDocument();
  });

  it("should show success message when the registration is successful.", async () => {
    render(<Register />);
    const buttonElement = screen.getByRole("button", {
      name: /register/i
    });
    await userEvent.click(buttonElement);
    const alertElement = screen.getByRole("alert");
    expect(alertElement).toBeInTheDocument();
  });
});

Conclusion

React Testing library is amazing and has become a very popular tool with which to test React applications.

Just remember that unlike enzyme testing library, you should not test for state changes when using React Testing Library.

So we have not written test cases to check if the state correctly changes after the user types some text in the name, email, or password fields.

In React Testing Library you check the behavior of DOM when the user clicks on a button or submits a form and so on instead of testing the internal state of the component.

Thanks for Reading!

You can find the complete source code for this tutorial in this repository.

If you want to become the best MERN stack developer (full stack developer), then do check out my course.

• This is a pre-recorded video course that will be constantly updated for any future changes.
• In this course, you will learn how to create React and Node.js applications from scratch and build an amazing online learning platform.
• After learning through this course, you will be able to build any MERN stack application confidently and easily.
• There is a separate section in this course, where you will learn how to test your entire React application using React testing library and jest.

So do check out this amazing course.

Want to stay up to date with regular content regarding JavaScript, React, Node.js? Follow me on LinkedIn.

🔐 Here's What We'll Cover

• You'll see how easy it is to set up your first unit tests in React.
• You'll improve your general React knowledge.
• You'll get the hang of why Test Driven Development (TDD) is helpful for your coding workflow.

📝 Prerequisites

• You should be familiar with the basic React workflow structure (including functional components and hooks).
• You should have a basic knowledge of Redux (I'm using Redux Toolkit for this guide).
• You don't need any prior knowledge about testing.
• I'm using the npm installation approach, not the yarn one.

🎯 The Objective

While learning advanced concepts of React, you'll probably stumble across the topic of testing. Being able to work with automatic tests is also quite handy for any upcoming frontend developers.

However, as I myself was learning React, I had a hard time finding information about how to implement tests for libraries like Redux (even though it's a library I work with all the time).

Beyond that, I found that doing any component testing in React is basically unfeasible when you don't know how to work with the Redux library.

So I took some time to read the Redux documentation and went back and forth with it a bit. Then I decided to write a practical starter guide for unit testing in React, including Redux, to share what I learned.

Since I would like to take a modern approach, I'm also going to use the Redux Toolkit. We'll cover the Redux implementation in this guide.

What we'll cover:

To start off, I will provide some general information about tests before I directly go into creating the first general unit tests.

Next I'll give a quick overview of how to implement some Redux Toolkit logic.

Then we will work on some unit tests within an application which uses Redux Toolkit. For this step we will adjust our previously created tests to the new Redux environment.

This is a step-by-step guide. If you are new to tests, I recommend following this guide in order from top to bottom.

I have also created a public GitHub repository for this guide with some commentary. You can use that if you want to look something up without scrolling through this guide in its full length again.

Table of Contents

1. What Different Kinds of Tests Are There?
2. How to Set Up Your React Testing Environment
3. Check Out Your Created React Application
4. How to Create Your First Unit Test
5. How to Create a Failing Test on Purpose
6. How to Create Some Additional Tests
7. How to Perform Testing with the React Redux Toolkit
8. Outlook for Advanced Testing

📋 What Different Kinds of Tests Are There?

This quick guide won't provide you with detailed theoretical knowledge about all the different kinds of testing out there. At this point, you should just understand that there are generally three kinds of tests:

• Unit Tests
• Integration Tests
• End-To-End Tests

To put it in simple words: You can see these three types of tests as generally increasing in their complexity.

While unit tests cover single functions and components, integration tests typically focus on multiple functions and their connections to each other. End-to-end tests are even more complex and give insights about multiple function and component structures.

There are other test concepts, but these three are the most important ones for web developers, for example.

Again, this is really put in simple words. But in this case it's sufficient to know that unit tests are basically the least complex tests out of these three.

It's also quite easy to work with unit tests as soon as you have a basic understanding of how testing in general works.

I would also like to quickly emphasize that there are mainly two ways of testing your application.

• Manual Testing
• Automatic Testing

Manual Testing is pretty much what you probably already do for all of your application which you create. When manually testing your application, you basically start your React application with npm run start and actually click on buttons to check if the corresponding function works.

Automatic Tests, on the other hand, are pretty much functions you create which automatically check your application to see if the respective steps work that you defined within these tests. This automatic kind of testing is extremely important for larger projects.

With this automatic approach, it's also way easier to scale your tests. In the end, you have a lot of tests which automatically test your whole application in a relatively short amount of time. These test can help you spot any potential errors which might have occurred during development. This would take much more time if you were to go back constantly to manually test your application.

Being able to work with automatic tests is also typically a big plus for your résumé as a frontend developer.

🔧 How to Set Up Your React Testing Environment

In order to get a practical start, we are going to directly dive into our React application.

You will see that the setup of a testing environment is relatively easy in React – or, to be more precise, React does it all for you during the regular install setup.

Therefore, I'm creating a React application with the following line:

npx create-react-app <name of your application>

After this step, we need everything that should be added for using Redux in our React application:

• React Redux: npm install react-redux (provides some mandatory hooks, for example)
• React Redux Toolkit: npm install @reduxjs/toolkit (provides logic for creating a store or slices, for example)

It's worth mentioning that there also is the Redux core (npm install redux). But this is already part of the React Redux Toolkit installation, so we don't have to install it here too.

If you wanted to use React without the React Redux Toolkit, then you would have to separately reach out to the Redux core installation.

You can also create a new React application from scratch with npx create-react-app my-app --template redux which includes the React Redux Toolkit, the React core, React Redux, as well as a template from the React Redux Toolkit.

Choose this approach if you don't have any existing React applications, since it's probably more convenient.

Under the hood, you now have an application that uses the React Testing library combined with Jest (a testing framework). Together, they have pretty much everything that you will need for testing your React application.

You don't have to install anything else for this purpose. These tools come out of the box with a standard React installation.

🔎 Check Out Your Created React Application

As you go into your newly created React application, you will find the folder and file structure you are likely familiar with. Besides others, there is the App.js file, which is created like this:

import logo from './logo.svg';
import './App.css';

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <img src={logo} className="App-logo" alt="logo" />
        <p>
          Edit <code>src/App.js</code> and save to reload.
        </p>
        <a
          className="App-link"
          href="https://reactjs.org"
          target="_blank"
          rel="noopener noreferrer"
        >
          Learn React
        </a>
      </header>
    </div>
  );
}

export default App;

Within the src folder, you also have the file App.test.js. This file is actually a first test that came out of the box with React installation. This file is structured like this:

import { render, screen } from '@testing-library/react';
import App from './App';

test('renders learn react link', () => {
  render(<App />);
  const linkElement = screen.getByText(/learn react/i);
  expect(linkElement).toBeInTheDocument();
});

Even without fully understanding what render or screen is, for example, we can see that something is going on with our App component in there. In fact, this is a unit test that is focusing on a specific part of the App component.

While this first template for a test is a handy representation of what a test looks like, I would like to create a test file from scratch.

Generally speaking, tests are separated into different test suites. These test suites are typically a group of tests that focus on the same component, for example. Tests within the same test suite basically have the same superordinate topic.

To check this, try to enter npm run test in your terminal when you are within your React application.

It could say something like "There are no new tests or changes since the last commit" – in this case, just enter a in the terminal to run all tests regardless.

In the end, you should be able to see this within the terminal:

Result of npm run test

At the top, you can see that the App.test.js file passed. Basically, all tests within this file were successful.

Below that, you can see renders learn react link: This is the description for this particular test, which we can define individually. We will get back to this later.

Further down, we can finally see the test suites and tests. As you can see, we have one test suite and one test. To be more precise, we have one test suite that includes this one test.

Later on, you will recognize that we will use like 1-3 test suites while there will be around 5+ tests, for example. Again, test suites basically provide a structure that groups single tests together.

The stuff with the snapshots is not important for your specific case.

Snapshots are an advanced concept for testing. So a reference snapshot (like an image that was taken) is being compared with the version after some actions took place. This can help to check whether the UI stays the same after some actions or if some changes happened all of a sudden.

I won't focus on testing with snapshots in this article. This is a topic that you might want to look up after understanding some unit testing basics.

🔨 How to Create Your First Unit Test

Now that we've looked at a unit test, lets dive into the first test which we'll build from scratch on our own.

For that, I would like to create a new folder called __tests__. This is common when you are working with tests or checking out other applications.

I'm also dragging the already-available App.test.js file into this folder. This doesn't change anything about the result.

Our folder structure now looks like this:

general folder structure with __tests__

Within __tests__, we create the file myFirstTesting.test.js. We need this file structure of <test name>.test.js. You can also create a test file with <test name>.spec.js – both approaches will work the same.

Our first step is to import the App.js component: import App from "../App";.

To create our first test, we have to make use of the test() function. You could also use it(). Both will achieve the same result.

The first parameter of this function has to be a string, which describes what we are going to test (remember the stuff with "renders learn react link" within the test file we viewed?). This is going to help you have a more precise overview after running all the tests.

In this case, I will use the description "renders logo in App component". The second parameter is another function for which we are using an anonymous arrow function. Our myFirstTesting.test.js file now looks like this:

import App from "../App";

test("renders logo in App component", () => {

})

Even though there is not much going on, let's try entering npm run test again. We will find the following result in our terminal:

Therefore, we now have two test files, resulting in two test suites and two tests.

Now we would actually like to test something. Since we added the description "renders logo in App component", we are going to test exactly that.

In order to do that, we need the render() function, which we'll use whenever we actually want to render a component from our application.

In order to add the render() function, we have to import it from the React Testing library, which is already part of our React application without any other installations.

While we're at this step of importing, let's also import screen (also part of the React Testing library). It provides access to different functions that will look through the current screen after something gets rendered and find specific elements, for example.

After adding these two imports, our myFirstTesting.test.js file now looks like this:

import App from "../App";
import { render, screen } from "@testing-library/react";

test("renders logo in App component", () => {

})

Now that we have all that, let's actually start working on our test.

First of all, we need to render our component. Remember that tests are self-contained and don't know that we have an App.js with the corresponding content in our React application. We have to individually tell the specific test that a component exists by rendering it with render() at the top of the test. This is going to look like this: render(<App />);.

Now that we have rendered the App.js component in this test, we should try to check if a specific content part can be found by the test. This way, we can actually test if App.js was rendered like it was supposed to be.

Assuming something went wrong, we would not be able to find the React logo, for example, which is currently part of the App.js component.

So we will try to find this logo, which is an img element. To do this, we can make use of the getByAltText() function that finds an element by its specific alt attribute, which is commonly utilized for images. We have access to this function with screen that we imported earlier.

We now have this expression: screen.getByAltText("logo"). So the test looks at the screen where we rendered the App.js component beforehand, and then gets an element, which has an alt attribute of "logo". We will connect all this to a variable.

Our test file now looks like this:

import App from "../App";
import { render, screen } from "@testing-library/react";

test("renders logo in App component", () => {
  render(<App />);
  const image = screen.getByAltText("logo");
})

There are a bunch of different functions like getByAltText() that you can use to look for elements with a specific text content, a specific role like a button, or even with a test id that you can add to the actual element.

You also have the opportunity to look for multiple elements. Besides that, you don't have to use a string as parameter. A regular expression with /logo/i is also feasible, for example. We will use different ways to find elements throughout this starter guide.

For the last step, we have to utilize expect(), which we use to see what behavior we can expect. In this case, we expect that our image variable is part of the component and therefore exists.

For this approach, our file would look like this:

import App from "../App";
import { render, screen } from "@testing-library/react";

test("renders logo in App component", () => {
  render(<App />);
  const image = screen.getByAltText("logo");
  expect(image).toBeInTheDocument();
})

❗ How to Create a Failing Test on Purpose

If we now run our tests with npm run test, everything will pass. Now, let's try to reverse this logic so that we actually create a failing test. This way, we can check if this test actually has some impact or not.

To do this, we can go into our App.js file and change the alt attribute for the logo image. If you change it to alt="loo", the test will fail and it'll give you some information.

In our case, though, I would like to change something on the test itself to make it fail and show you another expression that is handy to know. Instead of expect(image).toBeInTheDocument(); we can also type expect(image).not.toBeInTheDocument();. So here we added a not. This basically reversed the logic, and now the test expects that no such image element exists.

If we now try to run the test, we will find the following error message in our terminal:

The error message we get

You can see that the test expected that there was no such element as image. However, it found something and therefore answered with an error message.

You don't have to make all your tests purposely fail to check if they work or not. I just wanted to show you what an actual failing test would look like.

✏️ How to Create Some Additional Tests

Now we have finished with our first test and have some basic knowledge about what to expect when working with unit tests. Next, we will check out some other test examples.

In order to create a more realistic scenario, I will add one additional component, which we'll insert into the App.js component.

For this step, first we create a folder called components in our src folder. This is not a must, but it is common to structure your files like that.

Within the components folder, we create List.js. Our folder structure now looks like this:

current folder structure

Now, let's try to follow more of a test driven development (TDD) workflow, which is quite modern. I'm not necessarily sayint that this is always recommended. But a TDD approach is considered best practice by more and more people nowadays.

Of course, in this tutorial we'lre "only" talking about unit tests and not integration or end-to-end tests, but the general TDD workflow is similar for all three test categories.

So using this test driven development approach, we basically add tests and work on our application simultaneously.

To be more precise, we even create tests for single components and function parts before you even implement this tested logic in your application.

So there is a lot of going back and forth instead of creating all the tests at once at the end.

How to Start the Setup for List.js

In our example, we have added the List.js component. Within this component, I would like to add a list with a button. When a user clicks on the button, it adds something to the list (an object with multiple keys and values).

In order to have some sort of frame, I will first add some div elements and similar stuff to our List.js component before we dive into the actual logic.

The List.js component now looks like this:

const List = () => {
  return (
    <div
      style={{ marginLeft: "auto", marginTop: "500px", marginBottom: "500px" }}
    >
      <h1>This is a list</h1>
      <ul style={{ listStyleType: "none" }}>
        <li>This is the first list entry</li>
      </ul>
      <button>This button can add a new entry to the list</button>
    </div>
  );
};

export default List;

I also added the List.js component as a child to App.js (below all the other stuff in App.js) so it will be visible without changing anything else.

The result looks like this:

How it looks

This won't win you any style competitions but it's sufficient for our case.

Setup for the test for List.js

Since we want to test while we are working on our component, I will now jump directly to the testing part even if nothing really happened in our List.js component in terms of click functions, for example.

We could create a new test file, but I would like to show you a new function we can use for our test suites specifically. This function is called describe() and can be handy for further structuring our tests.

To use describe(), we jump to myFirstTesting.test.js within __tests__. Right now, this file basically serves as one test suite for the test we specifically created for the App.js component. But I would like to have two test suites within this test file: one for the App.js tests and one for the List.js tests.

For this step, I'm using the describe() function, which basically works like the test() function in terms of parameters.

The first parameter will be a string, describing the respective test suite. The second parameter is a function, which then includes our test() functions with their stuff.

It will look like this in our case:

import App from "../App";
import { render, screen } from "@testing-library/react";

describe("App.js component", () => {
  test("renders logo in App component", () => {
    render(<App />);
    const image = screen.getByAltText("logo");
    expect(image).toBeInTheDocument();
  });
});

describe("List.js component", () => {
  test("example", () => {});
});

Before we jump into this new test, I would actually like to add something for the App.js testing. Since we have this describe() block, we could just add a new test() function – and this is what I'm going to do.

See the following newly added test described with "renders List.js component in App.js":

import App from "../App";
import { render, screen } from "@testing-library/react";

describe("App.js component", () => {
  test("renders logo in App component", () => {
    render(<App />);
    const image = screen.getByAltText("logo");
    expect(image).toBeInTheDocument();
  });

   test("renders List.js component in App.js", () => {
    render(<App />);
    const textInListJS = screen.getByText(/This is a list/i);
    expect(textInListJS).toBeInTheDocument();
  });
});

describe("List.js component", () => {
  test("example", () => {});
});

So I'm rendering the App.js component and looking for text via a regular expression, which is part of the List.js component. This test can basically be understood as a render test for List.js. If List.js had not been able to be rendered within App.js, this test would not pass.

If you are confused that this works without separately using render() on the List.js component, remember that List.js is part of App.js and everything inside App.js will be rendered under typical conditions. If you tried to look for a text phrase that doesn't exist in List.js, this new test would fail. Right now, in our case, it passes.

I would also like to emphasize that you can have multiple expect() functions within the same test. Therefore, we also could have structured this new test like this:

import App from "../App";
import { render, screen } from "@testing-library/react";

describe("App.js component", () => {
  test("renders logo in App component", () => {
    render(<App />);
    const image = screen.getByAltText("logo");
    const textInListJS = screen.getByText(/This is a list/i);

    expect(image).toBeInTheDocument();
    expect(textInListJS).toBeInTheDocument();
  });
});

describe("List.js component", () => {
  test("example", () => {});
});

This would also work perfectly fine in our case. And this can be handy in situations where you test for some small elements which are directly connected to each other and have the same requirements to be rendered.

But keep in mind that in our case, we should have adjusted the description for this test. That's because "renders logo in App component" is not correct anymore if we are testing more than that in this test. So let's head back to the structure with two separate tests for now. But have in mind that you are able to work like this.

Back to the test for List.js

Now I would like to work with the second describe() block that we created a few moments ago, where we want to work with tests specifically for the List.js component.

Since we are aiming for a test-driven development approach, we should think about what we are going to build, write a test, and then implement that logic in our component.

We want to create a simple list in our List.js component. So there will be an array, which we will go through with map().

For this approach, we will utilize the useState() hook so we have a state that can dynamically adjust (the array of list items). Our first test will be to check if the length of this array in its initial state is equal to 1.

To find the items within this state, we will make use of the getAllByTestId() method, which allows us to search for specific elements we marked with a data-testid in the frontend.

The test with the description "renders initial state of listData state" that I created is now included:

import App from "../App";
import { render, screen } from "@testing-library/react";

describe("App.js component", () => {
  test("renders logo in App component", () => {
    render(<App />);
    const image = screen.getByAltText("logo");
    const textInListJS = screen.getByText(/This is a list/i);

    expect(image).toBeInTheDocument();
    expect(textInListJS).toBeInTheDocument();
  });
});

describe("List.js component", () => {
   test("renders initial state of listData state", () => {
    render(<List />);
    const list = screen.getAllByTestId("list-item");
    expect(list.length).toEqual(1);
  });
});

Right now this test will fail, of course, because we haven't added any of this logic to the component yet.

So I adjusted the List.js component. It now looks like this:

import { useState } from "react";

const List = () => {
  const initialState = [
    {
      id: `${new Date().getSeconds()}`,
      description: "This is something",
      significance: 7,
    },
  ];
  const [listData, setListData] = useState(initialState);

  return (
    <div
      style={{ marginLeft: "auto", marginTop: "500px", marginBottom: "500px" }}
    >
      <h1>This is a list</h1>
      <ul style={{ listStyleType: "none" }}>
        {listData.map((listItem) => {
          return (
            <li key={listItem.id} data-testid="list-item">
              {listItem.description}
            </li>
          );
        })}
      </ul>
      <button>This button can add a new entry to the list</button>
    </div>
  );
};

export default List;

Newly added was the listData state array via a useState() hook as well as an initialState, which I initialized with one object at the very top. I also made use of the map() function to go through this listData to create a list.

For each <li> element, I'm adding a key and a data-testid. This data-testid is the id we need for our test to find the respective elements.

On our actual application, we can see the listItem.description for this initial state:

So by manually testing (actually looking at our application in the browser), we can see that this should work. If we now run our tests, we will also see that the test we created passed.

How to add an object to the state

Now let's test something more exciting: the logic to add a new object to this listData state. Again, we will start by working on our test first before actually implementing the required logic within the React component.

With this newly added test described by "adds a new data entry to listData after button click", our test file now looks like this:

import App from "../App";
import List from "../components/List";
import { render, screen } from "@testing-library/react";

import userEvent from "@testing-library/user-event";

describe("App.js component", () => {
  test("renders logo in App component", () => {
    render(<App />);
    const image = screen.getByAltText("logo");
    expect(image).toBeInTheDocument();
  });

  test("renders List.js component in App.js", () => {
    render(<App />);
    const textInListJS = screen.getByText(/This is a list/i);
    expect(textInListJS).toBeInTheDocument();
  });
});

describe("List.js component", () => {
  test("renders initial state of listData state", () => {
    render(<List />);
    const list = screen.getAllByTestId("list-item");
    expect(list.length).toEqual(1);
  });

  test("adds a new data entry to listData after button click", () => {
    render(<List />);
    let listItems = screen.getAllByTestId("list-item");
    const button = screen.getByRole("button", {
      name: /This button can add a new entry to the list/i,
    });

    expect(list.length).toEqual(1);
    userEvent.click(button);
    list = screen.getAllByTestId("list-item");
    expect(list.length).toEqual(2);
  });
});

At the bottom, you can see this test. Therefore, we are first rendering the List.js component before looking for all available list items we assigned a test id to. You will see exactly where we put the test id in a few moments.

We also have to look for the button that we want to test to see if clicking on it adds something to the list. We do this with getByRole() which expects a role like "button" or "table" as a first parameter, for example (there are a bunch of different roles you can target). The second parameter is optional and is an object that can receive a value for the name key.

name is pretty much the text content we have specifically for the button in this case. This optional second parameter is handy when you have multiple elements of type "button" in your component and want to get a specific button out of these.

After getting the listItems as well as the button, we start off with a first expect() to basically test the initial state. In this initial state, we expect to have only one list item.

Then, with the help of userEvent, we are going to click on the button. You could also use fireEvent for this situation (userEvent is still pretty new compared to the fireEvent approach). Both will work, and both are helpful for any action where you want to interact with specific elements. In this case, I want to simulate clicking on a button.

Tests generally follow a "arrange -> act -> assert" pattern that you can follow to structure them. Within the "arrange" part, you initialize and get all required elements. With the "act" part, you would simulate a mouse click (as in our case), for example. With "assert," you are checking if it all behaves like you expected it to.

In another case, you could simulate changing the value of an input field with fireEvent.change(inputField, { target: { value: someValueVariable } }), for example. Maybe you want to focus an input field or even drag an element - such actions can be simulated via fireEvent and userEvent.

After the button click, it again looked for all listItems since the current value of this variable would still be 1 from the previous initialization. As soon as this step is completed, it uses another expect() function to check if the length of the listItems array is now equal to 2 and not 1.

Now that we have our test logic, let's jump back to the List.js component and implement the corresponding logic:

import { useState } from "react";

const List = () => {
  const initialState = [
    {
      id: `${new Date().getSeconds()}`,
      description: "This is something",
      significance: 7,
    },
  ];
  const [listData, setListData] = useState(initialState);

  return (
    <div
      style={{ marginLeft: "auto", marginTop: "500px", marginBottom: "500px" }}
    >
      <h1>This is a list</h1>
      <ul style={{ listStyleType: "none" }}>
        {listData.map((listItem) => {
          return (
            <li key={listItem.id} data-testid="list-item">
              {listItem.description}
            </li>
          );
        })}
      </ul>
      <button
        onClick={() =>
          setListData([
            ...listData,
            { id: 999, description: "999", significance: 100 },
          ])
        }
      >
        This button can add a new entry to the list
      </button>
    </div>
  );
};

export default List;

The only part that changed is the button at the bottom of this file. So I added a function that gets invoked when clicking on this button. The function then adjusts the current state of listData which is responsible for rendering our list. I copied the current state with a spread operator and then added another hard-coded object as the new entry for this list.

Of course, there are more creative ways to fill in the values for the id, description, and significance keys.

I would also like to emphasize that you have the opportunity to create a separate function outside of the return() and access this function like this: onClick={separateFunctionToAddObjectToState} on the same button element. This would also work without having to render something additional within the test.

If we now run our test, we will see that it passes. If you try to still expect a length of 1 after clicking on the button, the test will fail like this:

error alert for length of 1

So it actually does what it is supposed to do.

🔧 Setup for Redux

After working with local states via the useState() hook, I would like to work on the same files and adjust them for Redux (or the Redux Toolkit, to be precise).

I'm not going to dive deep into what Redux actually is and what every term like action, store, or reducer means in detail – since this would be worthy of a whole new guide. If you want that, you can read this guide to Redux basics.

Instead, I will give just a quick rundown and show which files I'm adding and editing. Then I'll talk about how to handle the render() method, including the Redux store provider, which can cause a lot of frustration when testing if you don't know about it.

Overall folder structure:

current overall folder structure with the React Redux Toolkit

You can see that I added an app (for the store) as well as a features (for the slice) folder.

Updated index.js file:

import React from "react";
import ReactDOM from "react-dom/client";
import "./index.css";
import App from "./App";
import reportWebVitals from "./reportWebVitals";
import { Provider } from "react-redux";
import store from "./app/store";

const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(
  <React.StrictMode>
    <Provider store={store}>
      <App />
    </Provider>
  </React.StrictMode>
);

You can see that I added a provider and wrapped it around the application so we have access to the store from anywhere.

Created store.js file:

import { configureStore } from "@reduxjs/toolkit";
import { ListSlice } from "../features/ListSlice";

const store = configureStore({
  reducer: {
    listReducers: listSlice.reducer,
  },
});

export default store;

In this file, we have created the required store for the Redux implementation.

Created ListSlice.js file in features folder:

import { createSlice } from "@reduxjs/toolkit";

export const initialState = {
  value: [
    {
      id: `${new Date().getSeconds()}`,
      description: "This is something",
      significance: 7,
    },
  ],
};

export const ListSlice = createSlice({
  name: "listReducers",
  initialState,
  reducers: {},
});

export const { } = ListSlice.actions;
export default ListSlice.reducer;

Here we have created the slice that we added to the store. Notice that I haven't added any reducer yet. This slice just contains the current corresponding state.

Updated List.js file in components folder:

import { useSelector, useDispatch } from "react-redux";

const List = () => {
  const listState = useSelector((state) => state.listReducers.value);
  const dispatch = useDispatch(); // not used right now

  return (
    <div
      style={{ marginLeft: "auto", marginTop: "500px", marginBottom: "500px" }}
    >
      <h1>This is a list</h1>
      <ul style={{ listStyleType: "none" }}>
        {listState.map((listItem) => {
          return (
            <li key={listItem.id} data-testid="list-item">
              {listItem.description}
            </li>
          );
        })}
      </ul>
      <button>This button can add a new entry to the list</button>
    </div>
  );
};

export default List;

On the frontend, we swapped the local state (using the useState hook) with the Redux state (using the useSelctor hook). You'll also see that I adjusted the button. There is no click function anymore (we will get back to that later on).

🔎 How to Perform Testing with the React Redux Toolkit

Now that we have updated and created all the necessary files for the React Redux Toolkit logic, I would like to run a quick test of all the tests we previously created.

The result is that all tests have failed:

Keep in mind that I adjusted the button in List.js, for example, so the corresponding test was expected to fail. However, not all tests should have failed.

The test environments are working in their own world. They don't know if you wrap a provider somewhere in index.js and enable Redux logic. So the tests are still trying to make the rendering work without Redux. But our application now depends on Redux to manage our main state.

This means that we have to adjust the render() function so that this function is actually aligned with the Redux logic.

A method to make this work is to introduce a helper function, which we will store in a new folder called utils. The file will be called utils-for-tests.jsx. The content will look like this:

import React from "react";
import { render } from "@testing-library/react";
import { configureStore } from "@reduxjs/toolkit";
import { Provider } from "react-redux";
// As a basic setup, import your same slice reducers
import { ListSlice } from "../features/ListSlice";

export function renderWithProviders(
  ui,
  {
    preloadedState = {},
    // Automatically create a store instance if no store was passed in
    store = configureStore({
      reducer: { listReducers: ListSlice.reducer },
      preloadedState,
    }),
    ...renderOptions
  } = {}
) {
  function Wrapper({ children }) {
    return <Provider store={store}>{children}</Provider>;
  }

  // Return an object with the store and all of RTL's query functions
  return { store, ...render(ui, { wrapper: Wrapper, ...renderOptions }) };
}

This code information can be found in the Redux documentation. You can almost copy and paste it all for your application.

But you have to adjust the slices that are used in there. Since in our application there is only the ListSlice we don't have much to add. Just import that and update the content of the configureStore() function, like we managed it in our store.js file.

This step is necessary to basically mock the entire Redux logic and put it together into one new render() function.

With that, we can import this new function into our test files (App.test.js and myFirstTesting.test.js) and then replace all render() functions with renderWithProviders(). The App.test.js file, for example, now looks like this:

import { screen } from "@testing-library/react";
import App from "../App";
import { renderWithProviders } from "../utils/utils-for-tests";

test("renders learn react link", () => {
  renderWithProviders(<App />);
  const linkElement = screen.getByText(/learn react/i);
  expect(linkElement).toBeInTheDocument();
});

There is not much more to do! If we now run our tests again (and comment out this one test, which is going to fail regardless because the button logic is not active anymore), it will work again.

Slice testing

Another exciting part about testing with Redux is testing the slices. If you created your application with the React Redux Toolkit template, then you will be provided with some corresponding tests.

For our case, I also want to implement a new test file where we will specifically test ListSlice.js and its corresponding Redux logic.

For this slice, we have to import the slice and the corresponding reducers we want to test. To start, I will import the slice and test if it gets initialized with the initialState.

This is actually not the TDD approach since we already manually tested this part. Netherless, I would like to implement an automatic test as well:

import ListSlice, { initialState } from "../features/ListSlice";

describe("tests for ListSlice", () => {
  test("initialize slice with initialValue", () => {
    const listSliceInit = ListSlice(initialState, { type: "unknown" });
    expect(listSliceInit).toBe(initialState);
  });
});

Notice that I'm using .spec instead of .test. This doesn't matter. You can choose either. In this case, I'm going with .spec to remind you that this is also a viable option.

Also remember that we exported the initialState within our slice (see above). So we are able to import it here.

Other than that, we are already familiar with the describe() environment, which includes one test(). Within this test, I'm initializing a variable listSliceInit, which will hold the value we are receiving after the slice operation took place.

For this operation, we use ListSlice as a function and include the initial state as the first argument (in this case initialState). The second argument will be a reducer in most cases.

But in this case, we don't need to enter a reducer. Instead, we are using an object with type: "unknown". This is basically telling the function that we don't want to perform any additional operations.

Therefore, listSliceInit should now include our state value, which includes an array with one entry. The corresponding test will pass.

To force a failure, I'm entering expect(listSliceInit).toBe({ value: [] }); instead of the previous expect() function. So instead of our initialState we are expecting it to have an empty array. Now our test environment will tell us the following:

failing test

So it actually tells us what exactly it expected – in this case, it expected the initialState.

Next, I would like to test a reducer. However, we haven't added one yet. So I will adjust ListSlice in the ListSlice.js file like this:

export const ListSlice = createSlice({
  name: "listReducers",
  initialState,
  reducers: {
    testAddReducer: (state, action) => {
      state.value.push(action.payload);
    },
  },
});

Thus, I added testAddReducer(), which is responsible for pushing one additional element to the current state value, which it receives via an input from the dispatch (through action.payload).

If we now jump back to the listSlice.spec.js file, I'm adding another unit test:

import ListSlice, { initialState, testAddReducer } from "../features/ListSlice";

describe("tests for ListSlice", () => {
  test("initialize slice with initialValue", () => {
    const listSliceInit = ListSlice(initialState, { type: "unknown" });
    expect(listSliceInit).toBe(initialState);
  });

  test("testAddReducer", () => {
    const testData = {
      id: `${new Date().getSeconds()}`,
      description: "This is for the test section",
      significance: 5,
    };

    const afterReducerOperation = ListSlice(
      initialState,
      testAddReducer(testData)
    );

    expect(afterReducerOperation).toStrictEqual({
      value: [initialState.value.at(0), testData],
    });
  });
});

I added the test for testAddReducer. You can see that I imported the reducer as well.

Firstly, I'm initializing a new variable, testData, which contains the data I would like to push to the current state.

After that, we follow the same structure as before with afterReducerOperation. But instead of this type: "unknown" stuff, we add the reducer as the second argument. This receives the testData as a parameter – basically like you would see it in a dispatch.

Then, we expect this afterReducerOperation variable to be strictly equal to the value of an array, which has two entries: initialState.value.at(0) (the first entry of our initialState) and testData. And this test will pass like we actually expected it.

If we are trying to enter some other entries or change the current ones, you would be able to see this test failing:

forced error: I added a third entry to the array

How to make the button click function work again

Remember the button click within the List.js component (for adding something to the listData state) that wasn't working anymore after we changed to the Redux setup? Let's quickly update that to make that logic work within a Redux environment for the sake of completeness. Since we have the required reducer now, this will be an easy step.

To make the test work again, which added a new element to the state, we have to adjust it a little on the frontend to implement the Redux logic. (Previously we used the useState hook for a local state.)

For this step, we are making use of the dispatch() function in order to reach out to the testAddReducer:

import { useSelector, useDispatch } from "react-redux";
import { testAddReducer } from "../features/ListSlice";

const List = () => {
  const listState = useSelector((state) => state.listReducers.value);
  const dispatch = useDispatch();

  return (
    <div
      style={{ marginLeft: "auto", marginTop: "500px", marginBottom: "500px" }}
    >
      <h1>This is a list</h1>
      <ul style={{ listStyleType: "none" }}>
        {listState.map((listItem) => {
          return (
            <li key={listItem.id} data-testid="list-item">
              {listItem.description}
            </li>
          );
        })}
      </ul>
      <button
        onClick={() =>
          dispatch(
            testAddReducer({
              id: `${new Date().getSeconds()}1`,
              description: "This is added",
              significance: 5,
            })
          )
        }
      >
        This button can add a new entry to the list
      </button>
    </div>
  );
};

export default List;

Besides the button logic, nothing else has changed in this file.

In the corresponding test (within myFirstTesting.test.js nothing has changed), if we now test everything – including this updated test – we will see that everything works fine:

final test run

And that's pretty much it for fundamental slice and general Redux unit testing!

🔭 Outlook for Advanced Testing

There are different topics like thunks (or RTK Query as an alternative) which could also be tested. But I'm considering this as an advanced topic, and it would take some more time to explain these processes.

If you are not aiming to be an expert in testing at this point, the topics we discussed for unit tests in Redux in this tutorial should be sufficient for you.

Generally speaking, I would recommend diving deeper into so-called mocks, spies, and also snapshots. These will be helpful if you are working on some other more advanced tests.

The stuff with renderWithProvider() is basically based on such a mock – there, we artificially created a store with reducers and a provider to create this new render() function. So mocks are especially helpful for any third-party libraries, for example.

As I said, though, mocks, spies, and snapshots are more of an advanced topic to wrap your head around.

📣 Further Learning Opportunities

I recently started to work on my first free Udemy course. While this first free course covers the basics of the React Redux Toolkit with German audio and manually added English subtitles, I'm also planning to publish other Udemy courses completely in English in the future.

I would really appreciate it if you would check out this cost-free course in order to provide me with some feedback.

Well, when working on a large project, you'll often have to update certain modules and refactor code as needed. But such changes can have unintended consequences on other modules that use an updated module within them. This can sometimes break existing functionality.

As a developer, you should test your code to ensure that all modules in the application work as intended. Unit tests let you check if small isolated units of code function correctly and enable you to fix inconsistencies that arise from updates and refactoring.

This guide will help you get started with unit testing in Python. You'll learn how to use Python's built-in unittest module to set up and run unit tests and write test cases to test Python functions. You'll also learn how to test functions that raise exceptions.

Let's get started!

Testing in Python – First Steps

We'll start by defining a Python function and write unit tests to check if it works as expected. To focus on how to set up unit tests, we'll consider a simple function is_prime(), that takes in a number and checks whether or not it is prime.

import math

def is_prime(num):
    '''Check if num is prime or not.'''
    for i in range(2,int(math.sqrt(num))+1):
        if num%i==0:
            return False
    return True

Let’s start a Python REPL, call the function is_prime() with arguments, and verify the results.

>>> from prime_number import is_prime
>>> is_prime(3)
True
>>> is_prime(5)
True
>>> is_prime(12)
False
>>> is_prime(8)
False
>>> assert is_prime(7) == True

You can also use the assert statement to verify that is_prime() returns the expected Boolean value, as shown above. If the return value from the function is different than the expected Boolean value, an AssertionError is raised.

This type of manual testing is inefficient when you want to exhaustively check your function for a much larger list of arguments. You may want to set up automated testing that runs and validates the function’s output against test cases defined in the test suite.

How to Use Python's unittest Module

Python ships with the unittest module that lets you configure automated tests for functions and classes in your application. The generic procedure to set up unit tests in Python is as follows:

# <module-name>.py

import unittest
from <module> import <function_to_test>
# all entries within <> are placeholders

class TestClass(unittest.TestCase):
    def test_<name_1>(self):
        # check function_to_test

    def test_<name_2>(self):
        # check function_to_test
    :
    :
    :

    def test_<name_n>(self):
        # check function_to_test

The above code snippet <module-name>.py does the following:

• Imports Python’s built-in unittest module.
• Imports the Python function to be tested, <function_to_test> from the module in which it’s defined, <module>.
• Creates a test class (TestClass) that inherits from unittest.TestCase class.
• Each of the tests that should be run should be defined as methods inside the test class.
• 💡 Note: For the unittest module to identify these methods as tests and run them, the names of these methods should start with test_.
• The TestCase class in the unittest module provides useful assertion methods to check if the function under test returns the expected values.

The most common assertion methods are listed below, and we’ll use some of them in this tutorial.

📑 For a complete list of assertion methods, refer to the unittest docs.

To run these tests, we should run unittest as the main module, using the following command:

$ python -m unittest <module-name>.py

We can add the if __name__=='__main__' conditional to run unittest as the main module.

if __name__=='__main__':
    unittest.main()

Adding the above conditional will enable us to run tests by directly running the Python module containing the tests.

$ python <module-name>.py

How to Define Test Cases for Python Functions

In this section, we’ll write unit tests for the is_prime() function using the syntax we’ve learned.

To test the is_prime() function that returns a Boolean, we can use the assertTrue() and assertFalse() methods. We define four test methods within the TestPrime class that inherits from unittest.TestCase.

import unittest
# import the is_prime function
from prime_number import is_prime
class TestPrime(unittest.TestCase):
    def test_two(self):
        self.assertTrue(is_prime(2))
    def test_five(self):
        self.assertTrue(is_prime(5))
    def test_nine(self):
        self.assertFalse(is_prime(9))
    def test_eleven(self):
        self.assertTrue(is_prime(11))
if __name__=='__main__':
    unittest.main()

$ python test_prime.py

In the output below, '.' indicates a successful test.

Output
....
----------------------------------------------------------------------
Ran 4 tests in 0.001s
OK

In the above code, there are four test methods, each checking for a specific input. You can instead define a single test method that asserts if the output is correct, for all four inputs.

import unittest
from prime_number import is_prime
class TestPrime(unittest.TestCase):
    def test_prime_not_prime(self):
        self.assertTrue(is_prime(2))
        self.assertTrue(is_prime(5))
        self.assertFalse(is_prime(9))
        self.assertTrue(is_prime(11))

Upon running the test_prime module, we see that one test has been run successfully. If any of the assert methods throw an AssertionError, then the test fails.

$ python test_prime.py

Output
.
----------------------------------------------------------------------
Ran 1 test in 0.001s
OK

How to Write Unit Tests to Check for Exceptions

In the previous section, we tested the is_prime() function with prime and non-prime numbers as inputs. Specifically, the inputs were all positive integers.

We haven't yet enforced that the arguments in the function call to is_prime() should be positive integers. You can use type hinting to enforce types or raise exceptions for invalid inputs.

In testing the is_prime() function, we haven't accounted for the following:

• For a floating point argument, the is_prime() function would still run and return True or False, which is incorrect.
• For arguments of other types, say, the string 'five' instead of the number 5, the function throws a TypeError.
• If the argument is a negative integer, then the math.sqrt() function throws a ValueError. The squares of all real numbers (positive, negative, or zero) are always non-negative. So square root is defined only for non-negative numbers.

Let's verify the above by running some examples in a Python REPL.

>>> from prime_number import is_prime

>>> is_prime('five')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/bala/unit-test-1/prime_number.py", line 5, in is_prime
for i in range(2,int(math.sqrt(num))+1):
TypeError: must be real number, not str

>>> is_prime(-10)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/home/bala/unit-test-1/prime_number.py", line 5, in is_prime
for i in range(2,int(math.sqrt(num))+1):
ValueError: math domain error

>>> is_prime(2.5)
True

How to Raise Exceptions for Invalid Inputs

To address the above, we'll validate the value used in the function call for num and raise exceptions as needed.

• Check if num is an integer. If yes, proceed to the next check. Else, raise a TypeError exception.
• Check if num is a negative integer. If yes, raise a ValueError exception.

Modifying the function definition to validate the input and raise exceptions, we have:

import math
def is_prime(num):
    '''Check if num is prime or not.'''
    # raise TypeError for invalid input type
    if type(num) != int:
        raise TypeError('num is of invalid type')
    # raise ValueError for invalid input value
    if num < 0:
        raise ValueError('Check the value of num; is num a non-negative integer?')
    # for valid input, proceed to check if num is prime
    for i in range(2,int(math.sqrt(num))+1):
        if num%i==0:
        return False
    return True

Now that we've modified the function to raise ValueError and TypeError for invalid inputs, the next step is to test if these exceptions are raised.

How to Use the assertRaises() Method to Test Exceptions

In the definition of the TestPrime class, let’s add methods to check if the exceptions are raised.

We define test_typeerror_1() and test_typeerror_2() methods to check if TypeError exception is raised and the test_valueerror() method to check if ValueError exception is raised.

📌 To call the assertRaises() method, we can use the following general syntax:

def test_exception(self):
    self.assertRaises(exception-name,function-name,args)

We can also use the following syntax using context manager (we’ll use this syntax in this example):

def test_exception(self):
    with self.assertRaises(exception-name):
        function-name(args)

Adding the test methods to check for exceptions, we have:

import unittest
from prime_number import is_prime
class TestPrime(unittest.TestCase):
    def test_prime_not_prime(self):
        self.assertTrue(is_prime(2))
        self.assertTrue(is_prime(5))
        self.assertFalse(is_prime(9))
        self.assertTrue(is_prime(11))
    def test_typeerror_1(self):
        with self.assertRaises(TypeError):
            is_prime(6.5)
    def test_typeerror_2(self):
        with self.assertRaises(TypeError):
            is_prime('five')
    def test_valueerror(self):
        with self.assertRaises(ValueError):
            is_prime(-4)

if __name__=='__main__':
    unittest.main()

Let's run the test_prime module and observe the output:

$ python test_prime.py

Output
....
----------------------------------------------------------------------
Ran 4 tests in 0.002s
OK

In the examples we’ve coded thus far, all the tests succeeded. Let’s modify one of the methods, say, test_typeerror_2(), to the following:

def test_typeerror_2(self):
    with self.assertRaises(TypeError):
        is_prime(5)

We call the function is_prime() with the number 5 as the argument. Here, 5 is a valid input for which the function returns True. Therefore, the function does not raise a TypeError. When we run the tests again, we’ll see that there’s one failing test.

$ python test_prime.py

Output

..F.
======================================================================
FAIL: test_typeerror_2 (__main__.TestPrime)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test_prime.py", line 17, in test_typeerror_2
is_prime(5)
AssertionError: TypeError not raised
----------------------------------------------------------------------
Ran 4 tests in 0.003s
FAILED (failures=1)

Conclusion

Thank you for reading this far! 😄 I hope this tutorial helped you understand the basics of unit testing in Python.

You've learned to set up tests that check if a function works as expected or raises an exception—all using Python's built-in unittest module.

Keep coding, and see you in the next tutorial!👩🏽‍💻

But software testing is a complex topic and can be a bit difficult to understand.

In this article, I'll explain the major topics in software testing and how this practice can help you.

Table of Contents:

• What is Software Testing?
• Types of Software Testing
• Different Types of Functional Software Testing
• Software Testing Principles
• Why is Software Testing needed?
• Conclusion

What is Software Testing?

Software testing is the process of making sure your software/app works as it should. There are various methods you can use to test your code, and each testing method has different requirements.

For instance, unit testing involves writing test cases to ensure the code works as it should, and Beta testing consists of testing the preview version of the software or app to make sure users can use the product.

Software testing is integral to the process of building good software that works as it should. It also helps improve productivity and performance. Testing is an important part of the Software Development Life Cycle (SDLC).

Other benefits of testing your code include preventing bugs, reducing cost, and reducing time of development.

Types of Software Testing

There are two general types of software testing:

Functional Testing:

Functional Testing is a software testing method that validates the system against the customer's requirements or specifications.

This type of testing aims to test each function of the software by providing the correct input and ensuring the output is right.

For examples, let's say you write a test case to test creating a user. The test case provides the correct input (email, first name, last name and password) and ensures the output (success message) is accurate, as well.

Functional testing checks that everything is functioning properly by emulating business scenarios based on applicable requirements.

Non-functional Testing:

Non-functional testing is a software testing method that tests for end-user experiences, such as performance and reliability under load. This could either make or break a user experience.

When your code fails at non-functional testing, it may not cause an issue that user would note but it can flag a problem in the system.

Non-functional testing is just about testing the software to know how it responds to load on the system.

In this guide, we will focus on Functional Software Testing.

Different Types of Functional Software Testing

There are different types of software testing, and each has a specific aim. We'll look at each one quickly now.

Unit Testing:

Unit testing is a type of software testing that validates how each software unit performs and whether that specific piece of code does what it should. A unit is the smallest testable component of an application.

The aim is to confirm that each unit of software code works as expected. You do unit testing during the coding (development) stage or phase. Developers write these tests as they go.

Unit tests isolate possible bugs in your code and help you correct them. A unit could be a single function, method, procedure, module, or object.

Code Snippet of a unit test case in Python

Code Snippet of a unit test case in Java

Integration Testing:

Integration Testing is software testing which helps ensure that software components or functions work together properly. This is the second phase of the software testing process that comes after unit testing.

In this type of testing, units or individual software components are tested in groups. This testing method mainly focuses on exposing defects in interactions between integrated components and units.

System Testing:

System testing involves the process of testing integrated software. The aim is to evaluate the system's compliance with specify requirements.

In system testing, the quality assurance team evaluates how each component of the application or software work together in a full, integrated environment.

Acceptance Testing:

Acceptance testing is a software testing method where a system is tested or checked for acceptability. It evaluates the system's compatibility with the business requirements and assesses whether it is acceptable for delivery.

It is also known as formal testing performed to fit user needs, requirements, and business processes. It determines if a system satisfies the standard business criteria and if users or customers will be able to accept it.

Acceptance testing is the last stage of software testing done after system testing and before making the system available for public use.

Regression Testing:

Regression testing ensures that a component continues working as it should, after including additional components in the program. You perform regression testing when something changes, such as adding a new module to the program.

This type of testing represents the complete testing of executed test cases that are re-executed to ensure the current functionalities still work just fine.

Alpha Testing and Beta Testing:

Alpha testing is also known as initial validation testing. It is an aspect of acceptance testing done before the product is given to the consumers or users. QA (Quality Assurance) testers usually do this. Alpha testing is done internally by the QA team.

Beta testing is also known as second phase of validation testing. But this type of testing is done externally, which means the public does it.

The version of the code/software for this phase of testing is released to a limited number of users for testing in a real-time scenario. For instance, freeCodeCamp's math curriculum is available for beta testing here.

Software Testing Principles

Everything in tech has principles. These are guidelines to help you build better software and avoid errors.

Here are some software testing principles you should follow when writing tests for your code:

Testing aims to show the presence of defects, not the absence:

Software testing aims to spot software failures. This reduces the presence of faults and errors.

Software testing ensures defects are visible to the developer but doesn't guarantee defect-free software. Multiple types of testing can't even ensure error-free software. Testing can only decrease the number of errors.

Exhaustive testing is not possible:

Exhaustive Testing is the process of testing software for all valid and invalid inputs and pre-conditions.

This method of testing is not realistic because test cases presume that the software is correct and it produces the correct output in every test case. If you truly try to test every aspect and test case in your software, it will take too much time and effort, and it's not practical.

Perform early testing:

Testing your software at an early phase helps avoid minor bugs or errors. When you can spot errors at an early stage of the Software Development Life Cycle(SDLC), it's always less expensive. It is best to start software testing from the beginning of the project.

Defect clustering:

Defect clustering refers to when most of the problems you find occur in just a few parts of the application or software. If you can identify the modules or areas where these defects occur, you can focus most of your testing efforts on them.

Keep the Pareto Principle in mind when testing your code: 80% of software defects tend to come from 20% of the modules.

Beware of the Pesticide paradox:

This principle is based on a theory – "the more you use pesticide on a crop, the more immune the crop will eventually grow, and the pesticide will not be effective."

When you repeat particular test cases over and over, you will see fewer and fewer new bugs. So to find new bugs, update your test cases and run them once you add new test cases.

Testing is context-dependent:

Testing is context-dependent, which means that you should test your software based on its needs, functionalities, and requirements.

Your test approach should depend on what your software does. Not every software needs the same type/method of testing because every application has its unique functionalities.

For instance, when testing an eCommerce web app, you will focus on its functionality to display products, so you will test how it shows products to end-users. When dealing with an API, you will focus on the response the API returns when an endpoint is called.

You wouldn't necessarily use the same test cases for both – that is what it means that testing is context-dependent.

The absence of errors is a fallacy:

If you build software that is 99% bug-free, but it doesn't follow user requirements, it is not usable for end-users.

Know that it is very much necessary that your 99% bug-free software still meets or fulfills your user requirements. It is important to write test cases to find errors in the code, but you also need to test your software for your end-users (with them and how they'll use it in mind). The best way to do this is to carry out beta testing.

Why is Software Testing Needed?

Besides making sure your software is bug-free and meets user requirements, software testing has other advantages.

Software testing improves security:

When building software, security is a crucial part of your planning. This is because vulnerable software could jeopardize you users and their information, as hackers can use stolen info for malicious purposes.

As a product undergoes testing, the end-user can count on the fact that they will be getting a reliable product and their details will be secured and safe. So users are more likely to get a product that is free from vulnerabilities with the help of software testing.

Software testing improves product quality:

You want your software or product to be bug-free, low-risk, and effective at what it should do. And you can achieve this by including test cases and other testing methods when building out the code.

In addition, you won't know how good your product is until you test it. This helps you provide the best product version before it gets released (and discover any inconsistencies or pain points along the way – so you can improve them).

Software testing improves customer satisfaction:

For instance, let's say you download a new app and try to use some of its functionality – but it shows an error. This will probably frustrate you, and you might not want to use the app again, right?

This is exactly why software testing is important. It can help you discover such errors and detect them before you release the product to the user, and gives the developers a chance to prevent the error.

By investing in software testing early in the development stage, you are letting the users know that you care about their experience. It could also help you create a solid long-term customer relationship.

Software testing saves money:

Software testing can save you a lot of money – but how?

Each stage of development involves many things, such as clear communication and coordination between multiple teams, and each step has a laundry list of things that could go awry.

Catching those errors when the product is live is a horrible experience because you may have to handle PR, retasking fixes, and trying to sort the problem in real time.

In addition, your users won't be able to access the app while you're fixing it, which defeats the app's purpose and provides a bad user experience in the meantime. Software testing helps resolve this stress, and once live, your user can enjoy your app/product to the fullest.

Conclusion

In conclusion, software testing is a crucial part of development. It can help save your team a lot of trouble, and it feels great to create a usable, bug-free product that users enjoy and recommend.

If software testing interests you, you can check freeCodeCamp's QA certificate course here to learn more about QA testing. QA testers are techies that focus on testing softwares and apps for errors.

Testing is an essential part of Software Development. Testing your code ensures that the software you develop works as expected and makes it less vulnerable to attackers.

Software testing is a very broad topic. That's why in the software industry, there are separate professionals who specialize in just QA and testing alone. These professionals are often referred to as QA Engineers.

Although QA is its own thing, that doesn't mean developers don't do testing at all.

The most common tests that developers conduct are Unit Tests. Unit testing is a type of testing where you test small units of code (like functions) – hence the term, Unit Testing. You often do this by comparing the expected behavior of a unit of code against its actual behavior.

Unit testing is such an integral part of the development workflow that some companies' whole development culture is centered around what's called Test-Driven Development (or TDD).

In TDD, developers first write test cases (from the feature requirements, often called the user story) and proceed to write the code that satisfies them. TDD shines mostly in projects where requirements are highly specific.

You can implement unit testing in different ways across different programming languages. But at its core, Unit Testing is just about comparing the expected vs the actual behavior of the code.

So regardless of how it's implemented in a particular language, the same principle generally applies when you work in any other language.

In this tutorial, you'll learn unit testing in the Rust programming language. That said, you should know at least the basics of programming in Rust although you don't need advanced knowledge of it.

This article will cover:

• How unit testing works in Rust
• How to write a unit test in Rust
• How to test a function
• Why failing tests are useful
• How to handle expected error behavior so that your tests won't fail

So, with all that said, let's proceed to learn unit testing with Rust!

How Unit Testing Works in Rust

Rust is built with code safety at its core. Rust's strict type annotation rules help eliminate a ton of bugs early on in the development phase. But still, it's not foolproof.

Like any other language, the business logic is on your shoulders and you have to help Rust understand what's acceptable in your code and what's not.

And yes, that's why we do testing.

You don't need to install a test suite to get started testing in Rust since it has built-in support for testing.

To get started, create a new cargo project (take note of the --lib flag) on your local machine and open it in the text editor or IDE of your choice. For this tutorial, I'll be using VS code.

cargo new --lib rust_unit_testing
code rust_unit_testing

Then, open the src/lib.rs file. This is where we'll spend the most time in this tutorial.

src/lib.rs file of a Rust Library Project

In a newly created library project in Rust, you'll notice that the lib.rs file is already pre-populated by a sample test code by default.

The main purpose of this is for you to have a template to begin with when writing your tests. We'll dissect each part of this simple test and understand the basic testing concepts in Rust.

So first, let's understand what those lines of test code are doing. In this example, you'll see a test module defined in lib.rs with one test inside it which tests if 2 + 2 is equal to 4.

If you don't know the concept of modules and attributes in Rust yet, that's fine and you can ignore them for now.

But just to give you an idea, tests in Rust are written inside the tests module (the mod tests part says it's the tests module), and anything written inside this module tells cargo to run them only during testing (and that's essentially what the #[cfg(test)] attribute implies).

A test in Rust is essentially just a function annotated as a test. From the example above, you'll notice the #[test] attribute above the function it_works. This simply tells cargo that this function is a test, and should be invoked during testing.

Inside the it_works test function, it checks if the value of result derived from 2 + 2 is equal to 4. It performs the checking using the assert_eq! macro. The assert_eq! macro compares the equality ( == ) of the left and right values passed onto it.

In most programming languages, there's a rule that the left values passed to the assert should be the expected values, while the actual value should be in the right. With Rust, there are no hard rules for that and you can pass on either side the expected and actual results.

Now, try running your test using this command:

cargo test

Here's what the result should look like for the example above:

cargo test - results

By running cargo test, cargo will execute your test cases and output the report in your terminal. From that report, you'll see the tests run by cargo.

The first line in the report says running 1 test since we only have one test function tests::it_works. Alongside the tested function, you'll see the message ok, meaning, the test passed.

You can also see the summary of the results below that:

• 1 passed
• 0 failed
• 0 ignored
• 0 measured
• 0 filtered out
• and the status of the result that says test result: ok

The 1 passed counter here represents that one test function (tests::it_works) that passed the test, while the failed counter tells how many failing tests we have. The same applies to the other counters as well.

You'll also see the results of the Doc-tests below. Since we don't have any doc tests here, you'll see running 0 tests. You can ignore this for now and just focus on the unit tests. But if you want to learn more, you can check Rust's official documentation.

How to Write Tests in Rust

When writing a test, you generally need to go through these three steps:

1. Mock the data or state needed for a test case. By this, I mean providing mock or sample data needed by the code you're testing (if necessary) and/or setting up the state or environment needed for the test case to run.
2. Run the code that needs to be tested (passing the mock data necessary). An example is invoking a function you want to test.
3. Check if the actual behavior of the code you're testing matches its expected behavior. For example, by passing an argument x to a function, you assert if its returned value is the same as what you're expecting for it to return. Or check if a unit of code raises panic!—which is the expected behavior, for example—if it's given a certain parameter.

In Rust, unit tests are written in the exact file where the code being tested is written. Test functions are then grouped inside the tests module (which is named this way by convention).

How to test functions in Rust

Now let's proceed to testing functions in Rust.

To begin with, we need a simple function to test. But first, remove the it_works test function since we no longer need it. Then, write this adder function above the tests module:

// src/lib.rs

pub fn adder(x: i32, y: i32) -> i32 {
    x + y
}

#[cfg(test)]
mod tests {
// ...

The adder function from above is a simple public function that just adds two numbers and returns the sum. To test if it works as expected, let's write a unit test for this function.

From the three steps of writing unit tests we discussed earlier, the first two steps are:

• set the data for the code to be tested
• run the code.

So going back to the tests module, first, bring the adder function into its scope (using the use keyword). Then write a function named it_adds annotated with the #[test] attribute.

// src/lib.rs

pub fn adder (x: i32, y: i32) -> i32 {
    x + y
}

#[cfg(test)]
mod tests {
    // this brings everything from parent's scope into this scope
    use super::*;

    #[test]
    fn it_adds() {
    }
}

Inside the it_adds test function is where we'll write the tests. So within it, declare a variable named sum, then call the function adder and pass 4 and 5 as its parameters (which are our mock data).

// src/lib.rs

// --snip--

    #[test]
    fn it_adds() {
        let sum = adder(4, 5);
    }
}

And finally, the third step in writing unit tests is to check the expected vs actual behavior of the code we're testing.

So here, let's assert if the value of sum as returned by the adder function is equal to 9 (which is our expected return value) using the assert_eq! macro.

// src/lib.rs

// --snip--

    #[test]
    fn it_adds() {
        let sum = adder(4, 5);
        assert_eq!(sum, 9);
    }
}

Here's the final version of our code and test in the lib.rs file:

// src/lib.rs

pub fn adder(x: i32, y: i32) -> i32 {
    x + y
}

#[cfg(test)]
mod tests {
    // this brings everything from parent's scope into this scope
    use super::*;

    #[test]
    fn it_adds() {
        let sum = adder(4, 5);
        assert_eq!(sum, 9);
    }
}

As you learned earlier, you can run this test using this command:

cargo test

If everything works well, we should get test result: ok stating that our tests passed.

You can add more tests in the tests module for the adder function if you like (for example, adding negative numbers). Or better yet, create your own function and write a test (or tests) for it.

Moreover, there are a lot more built-in assertion macros in Rust that you can use besides the assert_eq! macro. Some of those include the assert_ne! macro for asserting not equal values (!=), and the assert! macro which just asserts if the code you're testing returns a true value.

If you need more assertion macros (for example, comparison assertions that support >, <, >=, <=), you can install external crates like this one: claim. You can check claim's documentation here for more info.

Why Failing Tests Are Useful

So far we're always getting passing results on our tests.

Although it's good, the true power of unit tests comes from catching errors or bugs in our code and reporting them through failing tests. So for this time, let's intentionally write a 'buggy' code and see what happens.

Back in the lib.rs file, modify the adder function by replacing the + operator with -.

// src/lib.rs

pub fn adder(x: i32, y: i32) -> i32 {
    // change the operator from '+' to '-'
    x - y
}

// --snip--

Now run the tests again using cargo test. And as expected, you should see a failing test result like this:

failing test by cargo

First off, notice that the status of the test function tests::it_adds is a big red FAILED. This is what failing tests with cargo look like.

Below that, you'll see the 'failures' report which lists out the failing tests and some information as to why they failed.

From our example, the tests::it_adds test failed and as the report said, the left and right values passed into the assert_eq! macro aren't equal (==).

That's because the left value is -1 while the right value is 9. Remember that on our assert_eq! assertion, the left value that we passed to it is the sum variable that contains the return value of adder(4, 5).

Since our operator is wrong, the adder function performs 4 - 5 instead of the expected 4 + 5. That's why instead of the expected value of 9, we got -1. Cargo noticed this so it raised a failing test.

Below the failed tests report is its summary (sort of), still under the failures category, but just lists out the names of the test functions that failed.

And lastly, the entire summary of the overall test:

• Status is: test result: FAILED
• 0 passed
• 1 failed
• 0 ignored
• 0 measured
• 0 filtered out

This time, our failed counter is 1 (referring to our failed test function) while passed is 0.

How to Handle Expected Errors

From the previous section, you learned that errors cause tests to fail.

But what if you are expecting the code you're testing to fail (like for example, by giving it an invalid parameter). If it gets an error, cargo will flag this as a failing test even though you're actually expecting it to fail.

Can you expect failing behaviors?

The short answer is: yes, you can!

To demonstrate this, let's go back to the lib.rs file and modify our adder function. This time, let's set a rule for it to only accept single-digit integers (positive, zero, and negative) – otherwise, it should 'panic'. And for readability purposes, let's rename our adder function to single_digit_adder.

// src/lib.rs

// modify the `adder` function from earlier
// and turn it into `single_digit_adder`
pub fn single_digit_adder(x: i8, y: i8) -> i8 {
    fn is_single_digit(x: i8) -> bool {
        x < 10 && x > -10
    }

    if !(is_single_digit(x)) || !(is_single_digit(y)) {
        panic!("Only single digit integers are allowed!");
    } else {
        x + y
    }
}

#[cfg(test)]
mod tests {
// --snip--

Since we're expecting the single_digit_adder function to 'panic' whenever it receives a non-single digit integer, we need to specify that on the test function that's responsible for testing exactly this behavior.

To do that, we need to add another attribute to one of our test functions. And that is the #[should_panic] attribute.

Going back to the tests module, first, edit the it_adds test function by renaming the adder function call into single_digit_adder.

Then, create a new test function named it_should_only_accept_single_digits with both the #[test] and the #[should_panic] attribute.

Inside this new test function, call the single_digit_adder function with an invalid parameter (11) in this case.

// src/lib.rs

pub fn single_digit_adder(x: i8, y: i8) -> i8 {
    // ...
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn it_adds() {
        let sum = single_digit_adder(2, 3);
        assert_eq!(sum, 5);
    }

    // our new test function that expects `panic!` with invalid param
    #[test]
    #[should_panic]
    fn it_should_only_accept_single_digits() {
        single_digit_adder(11, 4);
    }
}

You don't need any assert macros in the it_should_only_accept_single_digits test function since we just need single_digit_adder to 'panic'. So simply calling the function is enough.

By giving it an invalid parameter (11, which isn't a single digit), we're expecting it to 'panic'. The #[should_panic] attribute will then expect that something should panic inside the it_should_only_accept_single_digits test function. If it didn't catch any panic, this test will fail. It will only pass if single_digit_adder panics.

So to test if it really works, try commenting the #[should_panic] attribute first and then run cargo test. You should expect it to fail.

Now, uncomment the #[should_panic] attribute and re-run the test. Your tests should all pass as expected:

The output of a test case expecting and actually catching a failing behavior

Notice that on the test tests::it_should_only_accept_single_digits, there's a should panic alongside it, and that it passed the test. This means that this test function caught a panic as expected.

And there you have it! You just learned what unit testing is and how to perform unit tests with the Rust programming language. Feel free to write your own tests using the knowledge you obtained from this article and use it in your future projects.

Conclusion

In this article, you learned what unit testing is and its importance in the software development process. You also learned how to write unit tests through the simple three steps process and actually perform testing in the Rust programming language.

We covered the structure of a test module in Rust and how to construct a test function, and then we wrote a simple Rust program and some test cases for it. We also covered failing tests and how to handle an expected failing behavior in the unit of code.

Testing is an important part of the software development process. Testing your code helps ensure that the software works as expected. As a developer, it's important that you test your code to ensure the quality of the software you're shipping and that those silly bugs don't reach the end-user!

So what is unit testing and how can you do it? You'll learn that and more in this article.

What is Unit Testing?

Unit testing is a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinised for process operation. - SearchSoftwareQuality

In basic terms, unit testing means that you break your application down to its simplest pieces and test these small pieces to ensure that each part is error free (and secure).

This testing is automated and written by software engineers as part of their development process. This is a very important step during development as it helps developers build better applications with fewer bugs.

What is PHPUnit?

You can perform unit testing in PHP with PHPUnit, a programmer-oriented testing framework for PHP. PHPUnit is an instance of the xUnit architecture for unit testing frameworks. It is very easy to install and get started with.

PHPUnit Installation

You can install PHPUnit globally on your server. You can also install it locally, on a per-project, development-time basis as a dependency to your project using composer. This article will explain how to use it on a per project basis.

To get started, create and initiate a new project with composer using these commands:

$ mkdir test-project
$ cd test-project
$ composer init

The first command creates a folder in your current directory, test-project and the second command moves into it. The last command starts an interactive shell.

Composer init prompt

Follow the prompt, filling in the details as required (the default values are fine). You can set the project description, author name (or contributors' names), minimum stability for dependencies, project type, license, and define your dependencies.

You can skip the dependencies part, as we are not installing any dependencies. PHPUnit is supposed to be a dev-dependency because testing as a whole should only happen during development.

Now, when the prompt asks Would you like to define your dev dependencies (require-dev) interactively [yes]?, press enter to accept. Then type in phpunit/phpunit to install PHPUnit as a dev-dependency.

Accept the other defaults and proceed to generating the composer.json file. The generated file should look like this currently:

{
    "name": "zubair/test-project",
    "require-dev": {
        "phpunit/phpunit": "^9.5"
    },
    "autoload": {
        "psr-4": {
            "Zubair\\TestProject\\": "src/"
        }
    },
    "authors": [
        {
            "name": "Idris Aweda Zubair",
            "email": "zubairidrisaweda@gmail.com"
        }
    ],
    "require": {}
}

To learn how to install PHPUnit globally on your server, read here.

How to Write Tests in PHPUnit

Writing tests in PHPUnit is quite simple. Here are a few conventions to get you started:

• To test a class in PHP, you'll create a test class named after that class. For example, if I had some sort of User class, the test class would be named UserTest.
• The test class, UserTest, will usually inherit the PHPUnit\Framework\TestCase class.
• Individual tests on the class are public methods named with test as a prefix. For example, to test a sayHello method on the User class, the method will be named testSayHello.
• Inside the test method, say testSayHello, you use PHPUnit's method like assertSame to see that some method returns some expected value.

A popular convention is to have all tests in a tests directory, and all source code in the src directory.

PHPUnit Testing Example

To help understand this article, here's a sample User class with simple methods that will be tested:

<?php

namespace Zubair\TestProject;

use InvalidArgumentException;

class User
{
    public int $age;
    public array $favorite_movies = [];
    public string $name;

    /**
     * @param int $age
     * @param string $name
     */
    public function __construct(int $age, string $name)
    {
        $this->age = $age;
        $this->name = $name;
    }

    public function tellName(): string
    {
        return "My name is " . $this->name . ".";
    }

    public function tellAge(): string
    {
        return "I am " . $this->age . " years old.";
    }

    public function addFavoriteMovie(string $movie): bool
    {
        $this->favorite_movies[] = $movie;

        return true;
    }

    public function removeFavoriteMovie(string $movie): bool
    {
        if (!in_array($movie, $this->favorite_movies)) throw new InvalidArgumentException("Unknown movie: " . $movie);

        unset($this->favorite_movies[array_search($movie, $this->favorite_movies)]);

        return true;
    }
}

This user class could be the User class in your movie streaming application. The user has a name, age, and a list of favourite movies that can be updated. For the rest of the article we will test that all these features work as they're expected to.

Create a UserTest class in the tests folder. Paste this in to start:

<?php

namespace Zubair\TestProject;

use PHPUnit\Framework\TestCase;

final class UserTest extends TestCase
{
    // Tests will go here
}

Test Constructor

Normally, you wouldn't be testing the __construct method. However, since we're setting values in it, it only makes sense to be sure that the values are being set correctly.

This seems like a very small thing to test, but that's the whole point of unit tests – to ensure that the smallest parts of your application function as expected.

Create a testClassConstructor method to test the constructor:

public function testClassConstructor()
{
    $user = new User(18, 'John');

    $this->assertSame('John', $user->name);
    $this->assertSame(18, $user->age);
    $this->assertEmpty($user->favorite_movies);
}

Let's take a quick break now, to see how to run the tests.

How to Run Tests in PHPUnit

You can run all the tests in a directory using the PHPUnit binary installed in your vendor folder.

$ ./vendor/bin/phpunit --verbose tests

You can also run a single test by providing the path to the test file.

$ ./vendor/bin/phpunit --verbose tests/UserTest.php

You use the --verbose flag to get more information on the test status.

Now, we can run the test and see the output:

Test Output

The output shows that we ran 1 test, and made 3 assertions in it. We also see how long it took to run the test, as well as how much memory was used in running the test.

These assertions are what PHPUnit uses to compare values returned from the methods to their expected value.

This example uses assertSame to check if the name and age properties on the user object match the entered values. It also uses assertEmpty to check that the favorite_movies array is empty.

To see a list of all these assertions, you can check out PHPUnit's docs here.

Edit the code to check if the user age is the same as 21.

public function testClassConstructor()
{
    $user = new User(18, 'John');

    $this->assertSame('John', $user->name);
    $this->assertSame(21, $user->age);
    $this->assertEmpty($user->favorite_movies);
}

Running the test again this time gives this output:

Failed Assertion Output

The output now shows that we ran 1 test, with 2 successful assertions, and also a failed one. We can see some explanation of the failure, showing the expected value, the gotten value, and the line where the error is from.

Test testName and tellAge

Next, we can test the testName method. This method tells the name of a user as a sentence. So, we can write the test to check:

• If the returned value is a string.
• If the returned string has the user's name in it (with or without case sensitivity).

public function testTellName()
{
    $user = new User(18, 'John');

    $this->assertIsString($user->tellName());
    $this->assertStringContainsStringIgnoringCase('John', $user->tellName());
}

The test uses the assertions assertIsString and assertStringContainsStringIgnoringCase to check that the return value is a string and that it contains the string John, respectively.

The testAge method is very similar to testName and uses the same logic. Its test will be similar to the previous one:

public function testTellAge()
{
    $user = new User(18, 'John');

    $this->assertIsString($user->tellAge());
    $this->assertStringContainsStringIgnoringCase('18', $user->tellAge());
}

Test addFavoriteMovie

We can test this method, too. This method adds a movie to the list of movies. To test it, we can check if the newly added movie is in the list, and that the number of items in the list actually increased.

The latter is for confirming that items are not being displaced. Also, since the function returns some value at the end, we can check that this value is correct too.

public function testAddFavoriteMovie()
{
    $user = new User(18, 'John');

    $this->assertTrue($user->addFavoriteMovie('Avengers'));
    $this->assertContains('Avengers', $user->favorite_movies);
    $this->assertCount(1, $user->favorite_movies);
}

Here, we use a few new assertions – assertTrue, assertContains, and assertCount – to check that the returned value is true, that it contains the newly added string, and that the array now has one item in it.

Test removeFavoriteMovie

Finally, we can test that the method to remove a movie works.

public function testRemoveFavoriteMovie()
{
    $user = new User(18, 'John');

    $this->assertTrue($user->addFavoriteMovie('Avengers'));
    $this->assertTrue($user->addFavoriteMovie('Justice League'));

    $this->assertTrue($user->removeFavoriteMovie('Avengers'));
    $this->assertNotContains('Avengers', $user->favorite_movies);
    $this->assertCount(1, $user->favorite_movies);
}

Here, we're adding some movies to the list. Then, we remove one of them, and confirm that the function returned true. Next, we confirm the removal by checking that the value is no longer in the list. Finally, we confirm that we have only one movie in the list, instead of two.

Conclusion

Now you know how to set up PHPUnit in your projects and how to test and ensure that you're building world class software. You can find all the code for this article here.

If you have any questions or relevant advice, please get in touch with me to share them.

To read more of my articles or follow my work, you can connect with me on LinkedIn, Twitter, and Github. It’s quick, it’s easy, and it’s free!

Let's say you're working on a coding project. You have been writing a bunch of code and staying up late at night to fix bugs. All this is part of the process before you release that software product.

Then you'll check your code to verify that it actually performs what it's been programmed to do. This is where software testing comes in.

This article will discuss the categories of Software Testing and the different types of testing developers most commonly use. You'll see that some of the tests are named for their function. So, when I say API test, I am referring to the tests carried out on the APIs consumed in your source code.

But before going further, let's make sure we know what we mean by Software Testing.

In simple terms, Software Testing is the process of checking the various aspects of a software product to validate the software’s specifications and make sure it's ready to use.

Objectives of Software Testing

From a single line code to a block of code, and even to the finished product, you test software to:

• check for defects and ensure that the product performs as specified
• make sure that the product meets market standards
• resolve any loopholes at the production stage
• prevent future malfunctions of the product

Characteristics of Software Testing

When you test your software, you want to make sure that your tests are:

• Practical
• Reliable
• Authentic
• Capable of finding errors
• Capable of checking the validity of your software

When Should You Test Your Software?

When you test your software will depend on what test you're wanting to perform.

You can test your software during the software development phase – that is, when writing the source code, as in the case of unit testing, API testing, and others.

You can also test after the software has been developed such as in User Interface (UI) Testing.

When Should Testing Stop?

You can stop testing your software when:

• All the necessary tests have been carried out efficiently
• Bugs in the source codes have been reduced to the barest minimum or eradicated
• Testers are done testing
• Product is fully secured against threats
• The product is released

Software Testing Methods

Now that you know what Software Testing means, how exactly is it done?

Software Testing is done based on two main methods:

1. Functional Testing
2. Non-functional Testing

The major difference between these categories of Software Testing is that Functional Testing tests the functionality of a software product while non-functional testing concentrates on the performance of the software product.

Functional Testing

Functional testing is the process of testing software to validate its usefulness with regard to its specifications.

In simple terms, it consists of various tests carried out on the software generally to verify its functionalities.

Functional testing helps the software team know if the software is working as required. Mind you, Functional Testing doesn't mean testing unit functions or modules.

Examples of Functional Testing

Unit Testing

In unit testing, you test individual units or functions of your software's source code. Unit testing can be done automatically or manually.

Automatic unit testing happens with human assistance while manual unit testing is actively done by humans.

The difference between these two methods is that the former is automated while the latter requires hard-coding.

The purpose of unit testing is to ensure that each unit component is working as expected.

API Testing

An application Programming Interface (or API) is a link between your program and an external source. So, if you want your program to do more than just what you code, you could employ the features of another program also. This is what consuming APIs is all about.

For instance, let's say that I want my application to have a map feature. Instead of coding one from the scratch, I could save myself some time and stress by using one of the readily available map APIs.

Using APIs, especially from external sources, comes with its pros and cons, though. And I bet you want to reduce the cons as much as possible. Well, this is why you need to test the API prior to product release.

When you consume a public or private API, while developing your software, you should check for the API's reliability, security, and effectiveness in your product prior to release.

Image representing API

UI (User interface) Testing

The User Interface is the channel of communication between the user and the software.

Every software product is developed with certain specifications for the User Interface. This means that the way the user interacts with the application is predetermined prior to developing the product.

In order to make sure that these specifications are met according to design, you can carry out tests on the UI – and this is known as UI Testing.

The UI Testing involves things like checking if the Sign-Up page is correctly accepting inputs, checking to see if the submit button is functional, and a host of other UI features.

Image of a Payment Page

Integration Testing

Putting components into groups for testing is known as integration testing. Integration testing involves checking how each separate component works together to achieve the common aim of the product.

For instance, in an e-commerce application, the integration tests can check how the Home page connects to the Carts page when the Cart menu is clicked.

The purpose of integration testing is to make sure that components are working in synchrony – that is, that component A works well with component B.

Image of two UI pages

Regression Testing

Software Development involves iteration, which often happens because of bugs in the source code.

After debugging your code, updating the software program, or making any other change to your code, you should test that software to validate its functionality. This testing is called Regression testing.

Examples of regression testing are corrective regression testing, selective regression testing, progressive regression testing, and others.

Non-functional or Performance Testing

Non-functional testing refers to the various tests carried out on a product to check its readiness for the market. Non-functional Tests go a step further to ensure the viability of a product and its worth.

Examples of Non-functional Testing

Volume Testing

The strength of every product lies in its ability to handle different volumes of data. Some software may not function with a large database. To avoid such breakage, you can do volume tests.

Volume test involves feeding a large database to the software to check its functionality based on the large volume of data. Testing your product on different volumes of data shows that your product can withstand more or fewer data at a given time.

Security Testing

In the world today, security is an important and much-discussed topic. Concerns range from physical security down to cyberspace – and everyone wants that assurance of safety when they are on the internet.

One of the issues you'll want to avoid as a software developer is threats to your application. You can perform security testing on your software product to check its level of vulnerability.

Security tests include authentication, authorization confidentiality, and other measures required to protect your software from risks and threats.

Where to put test files in a program folder

Your test files should be together in a test folder inside the root folder of your project. This is for easy navigation and integration into your project.

Conclusion

Now that you know the importance of testing in software development, you should make sure to write code that is error and bug-free when tested.

This will reduce the time you waste fixing bugs and will in turn make the product release date more achievable.

Lastly, be careful to put your test files in the same folder, especially for tests other than unit testing.