How do I compare objects in JUnit tests?

In JUnit tests, you usually compare objects with assertions, not with ==.

The most common choices are:

  • assertEquals(expected, actual) — compares objects using their equals() method.
  • assertSame(expected, actual) — checks whether both references point to the same object.
  • AssertJ’s assertThat(actual).isEqualTo(expected) — a more fluent alternative.
  • Field-by-field assertions — useful when you only care about some properties.

1. Comparing Objects with assertEquals()

In JUnit 5, use:

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;

class PersonTest {

    @Test
    void shouldCompareObjectsUsingEquals() {
        Person expected = new Person("Alice", 30);
        Person actual = new Person("Alice", 30);

        assertEquals(expected, actual);
    }
}

This works only if Person correctly overrides equals().

Example:

import java.util.Objects;

public class Person {
    private final String name;
    private final int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) {
            return true;
        }

        if (!(o instanceof Person person)) {
            return false;
        }

        return age == person.age &&
                Objects.equals(name, person.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(name, age);
    }
}

Now two different Person instances with the same values are considered equal.

2. Do Not Use == for Value Comparison

This checks whether both variables refer to the same object in memory:

Person p1 = new Person("Alice", 30);
Person p2 = new Person("Alice", 30);

assertEquals(p1, p2); // compares values using equals()

But this would fail:

import static org.junit.jupiter.api.Assertions.assertTrue;

assertTrue(p1 == p2); // false, because they are different objects

Use == only when you intentionally want to check reference identity.

3. Use assertSame() for Reference Comparison

If you want to verify that two references point to the exact same object, use assertSame():

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertSame;

class PersonTest {

    @Test
    void shouldReferToSameObject() {
        Person person = new Person("Alice", 30);

        Person samePerson = person;

        assertSame(person, samePerson);
    }
}

Use assertSame() for identity checks, not regular value comparison.

4. Compare Individual Fields

Sometimes you do not need full object equality. You may only care about specific fields:

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;

class PersonTest {

    @Test
    void shouldComparePersonFields() {
        Person actual = new Person("Alice", 30);

        assertEquals("Alice", actual.getName());
        assertEquals(30, actual.getAge());
    }
}

This is useful when:

  • the class does not override equals(),
  • only some fields matter,
  • generated fields like id, timestamps, or audit fields should be ignored.

5. Use AssertJ for More Readable Object Assertions

AssertJ provides fluent assertions:

import org.junit.jupiter.api.Test;

import static org.assertj.core.api.Assertions.assertThat;

class PersonTest {

    @Test
    void shouldCompareObjectsWithAssertJ() {
        Person expected = new Person("Alice", 30);
        Person actual = new Person("Alice", 30);

        assertThat(actual).isEqualTo(expected);
    }
}

You can also compare specific properties:

assertThat(actual)
        .extracting(Person::getName, Person::getAge)
        .containsExactly("Alice", 30);

Or compare objects recursively:

assertThat(actual)
        .usingRecursiveComparison()
        .isEqualTo(expected);

Recursive comparison is helpful when objects contain nested objects and you do not want to rely on every class implementing equals().

6. Comparing Lists of Objects

For lists, assertEquals() also uses equals() on each element:

import org.junit.jupiter.api.Test;

import java.util.List;

import static org.junit.jupiter.api.Assertions.assertEquals;

class PersonListTest {

    @Test
    void shouldCompareListsOfPeople() {
        List<Person> expected = List.of(
                new Person("Alice", 30),
                new Person("Bob", 25)
        );

        List<Person> actual = List.of(
                new Person("Alice", 30),
                new Person("Bob", 25)
        );

        assertEquals(expected, actual);
    }
}

The order must match. If order does not matter, AssertJ is often clearer:

assertThat(actual)
        .containsExactlyInAnyOrderElementsOf(expected);

7. Common Rule of Thumb

Use this:

assertEquals(expected, actual);

when you want to compare object values.

Use this:

assertSame(expected, actual);

when you want to check that both variables refer to the exact same object.

Avoid this for object value comparison:

expected == actual

because it checks identity, not logical equality.

Summary

Goal Recommended Assertion
Compare object values assertEquals(expected, actual)
Compare object references assertSame(expected, actual)
Compare selected fields assertEquals(expectedName, actual.getName())
Compare nested objects without relying on equals() AssertJ usingRecursiveComparison()
Compare lists in order assertEquals(expectedList, actualList)
Compare lists ignoring order AssertJ containsExactlyInAnyOrderElementsOf()

In most JUnit tests, object comparison starts with assertEquals(expected, actual), as long as the class has a proper equals() implementation.

How do I use AssertJ with JUnit for better assertions?

You can use AssertJ with JUnit to write more readable, fluent assertions than standard JUnit assertions.

1. Add AssertJ Dependency

If you use Maven:

<dependency>
    <groupId>org.assertj</groupId>
    <artifactId>assertj-core</artifactId>
    <version>3.26.3</version>
    <scope>test</scope>
</dependency>

If you use Gradle:

testImplementation("org.assertj:assertj-core:3.26.3")

2. Use AssertJ in a JUnit Test

Import assertThat statically:

import org.junit.jupiter.api.Test;

import static org.assertj.core.api.Assertions.assertThat;

class UserServiceTest {

    @Test
    void shouldReturnUserName() {
        String name = "Alice";

        assertThat(name)
                .isNotNull()
                .startsWith("A")
                .endsWith("e")
                .hasSize(5);
    }
}

3. AssertJ vs. JUnit Assertions

JUnit:

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;

assertEquals("Alice", name);
assertTrue(name.startsWith("A"));

AssertJ:

import static org.assertj.core.api.Assertions.assertThat;

assertThat(name)
        .isEqualTo("Alice")
        .startsWith("A");

AssertJ reads more naturally and usually gives better failure messages.

4. Common AssertJ Examples

Strings

assertThat(email)
        .isNotBlank()
        .contains("@")
        .endsWith(".com");

Numbers

assertThat(price)
        .isPositive()
        .isGreaterThan(10)
        .isLessThanOrEqualTo(100);

Collections

assertThat(users)
        .hasSize(3)
        .extracting(User::getName)
        .containsExactly("Alice", "Bob", "Charlie");

Objects

assertThat(user)
        .isNotNull()
        .extracting(User::getName, User::getEmail)
        .containsExactly("Alice", "[email protected]");

Exceptions

assertThatThrownBy(() -> userService.findById(-1L))
        .isInstanceOf(IllegalArgumentException.class)
        .hasMessageContaining("id");

Or with JUnit + AssertJ:

IllegalArgumentException exception =
        assertThrows(IllegalArgumentException.class, () -> userService.findById(-1L));

assertThat(exception)
        .hasMessageContaining("id");

5. Example with Spring/JUnit Test

import org.junit.jupiter.api.Test;

import static org.assertj.core.api.Assertions.assertThat;

class CalculatorTest {

    @Test
    void shouldAddNumbers() {
        Calculator calculator = new Calculator();

        int result = calculator.add(2, 3);

        assertThat(result).isEqualTo(5);
    }
}

6. Helpful AssertJ Tips

Use as() to describe assertions:

assertThat(user.getEmail())
        .as("user email should be valid")
        .contains("@");

Use recursive comparison for objects:

assertThat(actualUser)
        .usingRecursiveComparison()
        .isEqualTo(expectedUser);

Use containsExactlyInAnyOrder() when order does not matter:

assertThat(roles)
        .containsExactlyInAnyOrder("ADMIN", "USER");

Recommended Pattern

import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatThrownBy;

@Test
void shouldDoSomething() {
    // arrange
    User user = new User("Alice");

    // act
    String result = user.getName();

    // assert
    assertThat(result).isEqualTo("Alice");
}

In short: add assertj-core, statically import assertThat, and replace basic JUnit assertions with fluent AssertJ assertions for clearer and more expressive tests.

How do I test repository-like classes without a real database?

You can test repository-like classes without a real database by replacing the database dependency with a fake, mock, or in-memory implementation, depending on what you want to verify.

1. Use mocks for unit tests

If your class depends on a repository interface, mock it and verify behavior without touching a database.

Example with JUnit 5 and Mockito:

import org.junit.jupiter.api.Test;
import org.mockito.Mockito;

import java.util.Optional;

import static org.assertj.core.api.Assertions.assertThat;
import static org.mockito.Mockito.when;

class UserServiceTest {

    @Test
    void returnsUserName() {
        UserRepository userRepository = Mockito.mock(UserRepository.class);

        when(userRepository.findById(1L))
                .thenReturn(Optional.of(new User(1L, "Alice")));

        UserService service = new UserService(userRepository);

        String name = service.getUserName(1L);

        assertThat(name).isEqualTo("Alice");
    }
}

This is best when testing service logic, not repository implementation details.


2. Use a fake in-memory repository

If you have repository-like classes that are simple abstractions, create an in-memory fake.

import java.util.HashMap;
import java.util.Map;
import java.util.Optional;

class InMemoryUserRepository implements UserRepository {

    private final Map<Long, User> users = new HashMap<>();

    @Override
    public Optional<User> findById(Long id) {
        return Optional.ofNullable(users.get(id));
    }

    @Override
    public User save(User user) {
        users.put(user.id(), user);
        return user;
    }
}

Then use it in tests:

import org.junit.jupiter.api.Test;

import static org.assertj.core.api.Assertions.assertThat;

class UserServiceTest {

    @Test
    void savesAndLoadsUser() {
        UserRepository repository = new InMemoryUserRepository();
        UserService service = new UserService(repository);

        service.createUser(1L, "Alice");

        assertThat(service.getUserName(1L)).isEqualTo("Alice");
    }
}

This is useful when you want tests that are more realistic than mocks but still fast.


3. Use Spring @MockBean / @MockitoBean in Spring tests

For Spring MVC or service-layer tests, replace a repository bean with a mock.

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.test.context.bean.override.mockito.MockitoBean;
import org.springframework.boot.test.context.SpringBootTest;

import java.util.Optional;

import static org.mockito.Mockito.when;
import static org.assertj.core.api.Assertions.assertThat;

@SpringBootTest
class UserServiceSpringTest {

    @MockitoBean
    private UserRepository userRepository;

    @Autowired
    private UserService userService;

    @Test
    void returnsUserName() {
        when(userRepository.findById(1L))
                .thenReturn(Optional.of(new User(1L, "Alice")));

        assertThat(userService.getUserName(1L)).isEqualTo("Alice");
    }
}

Use this when you want Spring wiring but not database access.


4. Use @DataJpaTest with an embedded database

If you are testing a Spring Data JPA repository itself, mocks are usually not enough. You need to verify queries, mappings, transactions, and entity relationships.

For that, use an embedded database such as H2:

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;

import static org.assertj.core.api.Assertions.assertThat;

@DataJpaTest
class UserRepositoryTest {

    @Autowired
    private UserRepository userRepository;

    @Test
    void findsByEmail() {
        User user = new User();
        user.setName("Alice");
        user.setEmail("[email protected]");

        userRepository.save(user);

        User found = userRepository.findByEmail("[email protected]").orElseThrow();

        assertThat(found.getName()).isEqualTo("Alice");
    }
}

This does use a database, but not a “real” external one. It is fast and isolated.


5. Use Testcontainers for production-like repository tests

If your repository uses database-specific features, H2 may behave differently from PostgreSQL, MySQL, Oracle, etc.

In that case, use Testcontainers:

import org.junit.jupiter.api.Test;
import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;
import org.springframework.boot.testcontainers.service.connection.ServiceConnection;
import org.springframework.test.context.DynamicPropertyRegistry;
import org.testcontainers.containers.PostgreSQLContainer;
import org.testcontainers.junit.jupiter.Container;
import org.testcontainers.junit.jupiter.Testcontainers;

@DataJpaTest
@Testcontainers
class UserRepositoryTest {

    @Container
    @ServiceConnection
    static PostgreSQLContainer<?> postgres =
            new PostgreSQLContainer<>("postgres:16");

    @Test
    void testRepository() {
        // repository test here
    }
}

This is not a local “real database” you manage manually, but it gives you much higher confidence.


Recommended approach

What you are testing Recommended technique
Service using a repository Mock repository
Business logic with persistence-like behavior Fake in-memory repository
Spring wiring without DB @MockitoBean
JPA mappings and queries @DataJpaTest
DB-specific SQL/features Testcontainers

Rule of thumb

Do not unit test Spring Data JPA repositories by mocking JPA internals like EntityManager unless your repository has significant custom logic.

Instead:

  • Mock repositories when testing services.
  • Use fakes when testing domain/application logic.
  • Use @DataJpaTest or Testcontainers when testing actual persistence behavior.

How do I test service classes with JUnit and Mockito?

Testing Service Classes with JUnit and Mockito

Service classes are usually where your business logic lives. They often depend on repositories, clients, mappers, validators, or other services.

When unit testing a service, the goal is usually:

  • test the service logic itself
  • mock external dependencies
  • avoid starting the Spring container unless necessary
  • verify returned values, exceptions, and interactions

For most service unit tests, you can use JUnit 5 with Mockito.


1. Example Service Class

Suppose you have a service that creates and retrieves users.

package com.example.user;

import java.util.Optional;

public class UserService {

    private final UserRepository userRepository;
    private final EmailValidator emailValidator;

    public UserService(UserRepository userRepository, EmailValidator emailValidator) {
        this.userRepository = userRepository;
        this.emailValidator = emailValidator;
    }

    public User createUser(String name, String email) {
        if (!emailValidator.isValid(email)) {
            throw new IllegalArgumentException("Invalid email address");
        }

        if (userRepository.existsByEmail(email)) {
            throw new IllegalStateException("Email already exists");
        }

        User user = new User(null, name, email);
        return userRepository.save(user);
    }

    public User getUserById(Long id) {
        return userRepository.findById(id)
                .orElseThrow(() -> new UserNotFoundException("User not found: " + id));
    }
}

Supporting classes might look like this:

package com.example.user;

public record User(Long id, String name, String email) {
}
package com.example.user;

import java.util.Optional;

public interface UserRepository {
    boolean existsByEmail(String email);

    User save(User user);

    Optional<User> findById(Long id);
}
package com.example.user;

public interface EmailValidator {
    boolean isValid(String email);
}
package com.example.user;

public class UserNotFoundException extends RuntimeException {
    public UserNotFoundException(String message) {
        super(message);
    }
}

2. Add JUnit and Mockito Dependencies

Maven

<dependencies>
    <!-- JUnit 5 -->
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>5.11.4</version>
        <scope>test</scope>
    </dependency>

    <!-- Mockito + JUnit 5 integration -->
    <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-junit-jupiter</artifactId>
        <version>5.15.2</version>
        <scope>test</scope>
    </dependency>
</dependencies>

If you use Maven, also make sure Surefire supports JUnit 5:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>3.5.2</version>
        </plugin>
    </plugins>
</build>

Gradle

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter:5.11.4'
    testImplementation 'org.mockito:mockito-junit-jupiter:5.15.2'
}

test {
    useJUnitPlatform()
}

3. Basic Service Test with Mockito

Use @ExtendWith(MockitoExtension.class) to enable Mockito in JUnit 5.

package com.example.user;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

import java.util.Optional;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;
import static org.junit.jupiter.api.Assertions.assertTrue;
import static org.mockito.ArgumentMatchers.any;
import static org.mockito.Mockito.never;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;

@ExtendWith(MockitoExtension.class)
class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @Mock
    private EmailValidator emailValidator;

    @InjectMocks
    private UserService userService;

    @Test
    void createUser_WithValidEmailAndNewEmail_ReturnsSavedUser() {
        // Arrange
        String name = "Alice";
        String email = "[email protected]";

        User savedUser = new User(1L, name, email);

        when(emailValidator.isValid(email)).thenReturn(true);
        when(userRepository.existsByEmail(email)).thenReturn(false);
        when(userRepository.save(any(User.class))).thenReturn(savedUser);

        // Act
        User result = userService.createUser(name, email);

        // Assert
        assertEquals(1L, result.id());
        assertEquals("Alice", result.name());
        assertEquals("[email protected]", result.email());

        verify(emailValidator).isValid(email);
        verify(userRepository).existsByEmail(email);
        verify(userRepository).save(any(User.class));
    }

    @Test
    void createUser_WithInvalidEmail_ThrowsException() {
        // Arrange
        String email = "invalid-email";

        when(emailValidator.isValid(email)).thenReturn(false);

        // Act
        IllegalArgumentException exception = assertThrows(
                IllegalArgumentException.class,
                () -> userService.createUser("Alice", email)
        );

        // Assert
        assertEquals("Invalid email address", exception.getMessage());

        verify(emailValidator).isValid(email);
        verify(userRepository, never()).existsByEmail(email);
        verify(userRepository, never()).save(any(User.class));
    }

    @Test
    void createUser_WithExistingEmail_ThrowsException() {
        // Arrange
        String email = "[email protected]";

        when(emailValidator.isValid(email)).thenReturn(true);
        when(userRepository.existsByEmail(email)).thenReturn(true);

        // Act
        IllegalStateException exception = assertThrows(
                IllegalStateException.class,
                () -> userService.createUser("Alice", email)
        );

        // Assert
        assertEquals("Email already exists", exception.getMessage());

        verify(emailValidator).isValid(email);
        verify(userRepository).existsByEmail(email);
        verify(userRepository, never()).save(any(User.class));
    }

    @Test
    void getUserById_WhenUserExists_ReturnsUser() {
        // Arrange
        User user = new User(1L, "Alice", "[email protected]");

        when(userRepository.findById(1L)).thenReturn(Optional.of(user));

        // Act
        User result = userService.getUserById(1L);

        // Assert
        assertEquals(user, result);

        verify(userRepository).findById(1L);
    }

    @Test
    void getUserById_WhenUserDoesNotExist_ThrowsException() {
        // Arrange
        when(userRepository.findById(99L)).thenReturn(Optional.empty());

        // Act
        UserNotFoundException exception = assertThrows(
                UserNotFoundException.class,
                () -> userService.getUserById(99L)
        );

        // Assert
        assertTrue(exception.getMessage().contains("99"));

        verify(userRepository).findById(99L);
    }
}

4. What @Mock and @InjectMocks Do

@Mock

Creates fake versions of dependencies.

@Mock
private UserRepository userRepository;

This means you control what the repository returns:

when(userRepository.findById(1L))
        .thenReturn(Optional.of(user));

@InjectMocks

Creates the service under test and injects the mocks into it.

@InjectMocks
private UserService userService;

Mockito will try constructor injection first, which works well if your service uses constructor injection.


5. Typical Test Structure

A clean service test usually follows Arrange, Act, Assert:

@Test
void methodName_StateUnderTest_ExpectedBehavior() {
    // Arrange
    when(repository.findById(1L)).thenReturn(Optional.of(entity));

    // Act
    Result result = service.method(1L);

    // Assert
    assertEquals(expected, result);
    verify(repository).findById(1L);
}

6. Testing Exceptions

Use assertThrows() when the service should reject invalid input or missing data.

@Test
void getUserById_WhenUserMissing_ThrowsException() {
    when(userRepository.findById(1L)).thenReturn(Optional.empty());

    UserNotFoundException exception = assertThrows(
            UserNotFoundException.class,
            () -> userService.getUserById(1L)
    );

    assertEquals("User not found: 1", exception.getMessage());
}

7. Verifying Repository Calls

Mockito can check whether a dependency method was called.

verify(userRepository).findById(1L);

You can also verify that something was not called:

verify(userRepository, never()).save(any(User.class));

This is useful when testing validation failures.


8. Capturing Arguments

Sometimes you need to inspect the object passed to a mocked dependency.

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.ArgumentCaptor;
import org.mockito.Captor;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Mockito.verify;

@ExtendWith(MockitoExtension.class)
class UserServiceArgumentCaptorTest {

    @Mock
    private UserRepository userRepository;

    @Mock
    private EmailValidator emailValidator;

    @InjectMocks
    private UserService userService;

    @Captor
    private ArgumentCaptor<User> userCaptor;

    @Test
    void createUser_PassesCorrectUserToRepository() {
        // Arrange
        when(emailValidator.isValid("[email protected]")).thenReturn(true);
        when(userRepository.existsByEmail("[email protected]")).thenReturn(false);
        when(userRepository.save(any(User.class)))
                .thenAnswer(invocation -> invocation.getArgument(0));

        // Act
        userService.createUser("Alice", "[email protected]");

        // Assert
        verify(userRepository).save(userCaptor.capture());

        User capturedUser = userCaptor.getValue();

        assertEquals("Alice", capturedUser.name());
        assertEquals("[email protected]", capturedUser.email());
    }
}

Additional imports needed for this example:

import static org.mockito.ArgumentMatchers.any;
import static org.mockito.Mockito.when;

9. When Should You Use @SpringBootTest?

For normal service unit tests, you usually do not need this:

@SpringBootTest

@SpringBootTest starts the Spring application context, which makes tests slower and more integration-style.

Use plain Mockito tests when you want to test only the service logic:

@ExtendWith(MockitoExtension.class)
class UserServiceTest {
}

Use @SpringBootTest when you want to test that Spring wiring, configuration, transactions, database integration, or multiple beans work together.


10. Service Test Checklist

When testing service classes:

  • Mock repositories and external clients.
  • Use the real service class.
  • Test successful paths.
  • Test validation failures.
  • Test missing data scenarios.
  • Test exception paths.
  • Verify important dependency calls.
  • Avoid testing getters, setters, or framework behavior.
  • Avoid starting Spring unless you need integration testing.
  • Prefer constructor injection in your service classes.

Summary

To test service classes with JUnit and Mockito:

  1. Add junit-jupiter and mockito-junit-jupiter.
  2. Annotate the test with @ExtendWith(MockitoExtension.class).
  3. Mock dependencies with @Mock.
  4. Create the service with @InjectMocks.
  5. Stub dependency behavior with when(...).thenReturn(...).
  6. Call the service method.
  7. Assert the result with JUnit assertions.
  8. Verify interactions with Mockito when useful.

For most service classes, this gives you fast, focused, and reliable unit tests.

How do I mock exceptions in JUnit tests?

In JUnit tests, you usually don’t “mock” exceptions directly. Instead, you either:

  1. Assert that real code throws an exception, or
  2. Configure a mock dependency to throw an exception.

1. Assert that code throws an exception

With JUnit 5, use assertThrows.

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;

class MyServiceTest {

    @Test
    void shouldThrowException() {
        IllegalArgumentException exception = assertThrows(
                IllegalArgumentException.class,
                () -> {
                    throw new IllegalArgumentException("Invalid input");
                }
        );

        assertEquals("Invalid input", exception.getMessage());
    }
}

assertThrows verifies that the code inside the lambda throws the expected exception type.

2. Mock a dependency to throw an exception with Mockito

If your class depends on another object, you can configure the mock to throw an exception.

import org.junit.jupiter.api.Test;
import org.mockito.Mockito;

import static org.junit.jupiter.api.Assertions.assertThrows;
import static org.mockito.Mockito.when;

class UserServiceTest {

    @Test
    void shouldThrowWhenRepositoryFails() {
        UserRepository repository = Mockito.mock(UserRepository.class);

        when(repository.findById(1L))
                .thenThrow(new RuntimeException("Database error"));

        UserService service = new UserService(repository);

        assertThrows(
                RuntimeException.class,
                () -> service.getUser(1L)
        );
    }
}

3. Mock exceptions for void methods

For void methods, use doThrow.

import org.junit.jupiter.api.Test;
import org.mockito.Mockito;

import static org.junit.jupiter.api.Assertions.assertThrows;
import static org.mockito.Mockito.doThrow;

class NotificationServiceTest {

    @Test
    void shouldThrowWhenEmailFails() {
        EmailClient emailClient = Mockito.mock(EmailClient.class);

        doThrow(new RuntimeException("Email failed"))
                .when(emailClient)
                .sendEmail("[email protected]");

        NotificationService service = new NotificationService(emailClient);

        assertThrows(
                RuntimeException.class,
                () -> service.notifyUser("[email protected]")
        );
    }
}

4. Check the exception message

You can capture the thrown exception and verify its message.

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertThrows;

class CalculatorTest {

    @Test
    void shouldThrowArithmeticException() {
        ArithmeticException exception = assertThrows(
                ArithmeticException.class,
                () -> {
                    int result = 10 / 0;
                }
        );

        assertEquals("/ by zero", exception.getMessage());
    }
}

5. JUnit 4 alternative

If you are using JUnit 4, you can use the expected attribute.

import org.junit.Test;

public class CalculatorTest {

    @Test(expected = ArithmeticException.class)
    public void shouldThrowArithmeticException() {
        int result = 10 / 0;
    }
}

However, in JUnit 4, ExpectedException or AssertJ is better if you need to check the message.

import org.junit.Rule;
import org.junit.Test;
import org.junit.rules.ExpectedException;

public class CalculatorTest {

    @Rule
    public ExpectedException exception = ExpectedException.none();

    @Test
    public void shouldThrowWithMessage() {
        exception.expect(IllegalArgumentException.class);
        exception.expectMessage("Invalid input");

        throw new IllegalArgumentException("Invalid input");
    }
}

Quick rule of thumb

  • Use assertThrows when testing your own method throws an exception.
  • Use when(...).thenThrow(...) for mocked methods that return a value.
  • Use doThrow(...).when(...) for mocked void methods.

For modern Java projects, prefer JUnit 5 + Mockito:

assertThrows(SomeException.class, () -> service.method());

How do I verify method calls with Mockito and JUnit?

To verify method calls with Mockito and JUnit, use Mockito’s verify() method. This lets you check whether a mocked dependency method was called, how many times it was called, and what arguments were passed.

1. Basic Example

Suppose you have a service that depends on a repository.

public interface UserRepository {
    void save(User user);
}
public class UserService {
    private final UserRepository userRepository;

    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public void register(User user) {
        userRepository.save(user);
    }
}

You can verify that save() was called:

import org.junit.jupiter.api.Test;

import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;

class UserServiceTest {

    @Test
    void register_shouldSaveUser() {
        UserRepository userRepository = mock(UserRepository.class);
        UserService userService = new UserService(userRepository);

        User user = new User();

        userService.register(user);

        verify(userRepository).save(user);
    }
}

The important line is:

verify(userRepository).save(user);

This means: “After running the test, confirm that save(user) was called on userRepository.”

2. Verifying Number of Calls

By default, verify() expects the method to be called exactly once.

These two lines are equivalent:

verify(userRepository).save(user);
verify(userRepository, times(1)).save(user);

You can verify different call counts:

import static org.mockito.Mockito.never;
import static org.mockito.Mockito.times;
import static org.mockito.Mockito.verify;

verify(userRepository, times(1)).save(user);
verify(userRepository, times(2)).save(user);
verify(userRepository, never()).delete(user);

Common options include:

verify(mock, times(1)).method();
verify(mock, never()).method();
verify(mock, atLeastOnce()).method();
verify(mock, atLeast(2)).method();
verify(mock, atMost(3)).method();

Example:

import org.junit.jupiter.api.Test;

import static org.mockito.Mockito.atLeastOnce;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;

class NotificationServiceTest {

    @Test
    void sendWelcomeEmail_shouldNotifyUser() {
        EmailSender emailSender = mock(EmailSender.class);
        NotificationService notificationService = new NotificationService(emailSender);

        notificationService.sendWelcomeEmail("[email protected]");

        verify(emailSender, atLeastOnce()).send("[email protected]", "Welcome!");
    }
}

3. Verifying Arguments with Matchers

If you do not want to match the exact object, you can use argument matchers.

import static org.mockito.ArgumentMatchers.any;
import static org.mockito.ArgumentMatchers.eq;
import static org.mockito.Mockito.verify;

verify(userRepository).save(any(User.class));

For specific values:

verify(emailSender).send(eq("[email protected]"), eq("Welcome!"));

You can also mix broad and specific matching:

verify(emailSender).send(eq("[email protected]"), any(String.class));

Important: if you use matchers for one argument, use matchers for all arguments in that method call.

Correct:

verify(emailSender).send(eq("[email protected]"), any(String.class));

Avoid mixing raw values and matchers:

verify(emailSender).send("[email protected]", any(String.class));

4. Verifying No Calls

To verify that a mock had no interactions:

import static org.mockito.Mockito.verifyNoInteractions;

verifyNoInteractions(userRepository);

To verify that no more calls happened after the expected ones:

import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.verifyNoMoreInteractions;

verify(userRepository).save(user);
verifyNoMoreInteractions(userRepository);

Example:

@Test
void register_invalidUser_shouldNotSaveUser() {
    UserRepository userRepository = mock(UserRepository.class);
    UserService userService = new UserService(userRepository);

    User invalidUser = new User();

    userService.register(invalidUser);

    verifyNoInteractions(userRepository);
}

5. Verifying Order of Calls

Use InOrder when the order matters.

import org.junit.jupiter.api.Test;
import org.mockito.InOrder;

import static org.mockito.Mockito.inOrder;
import static org.mockito.Mockito.mock;

class OrderServiceTest {

    @Test
    void processOrder_shouldCallMethodsInOrder() {
        PaymentService paymentService = mock(PaymentService.class);
        InventoryService inventoryService = mock(InventoryService.class);

        OrderService orderService = new OrderService(paymentService, inventoryService);

        Order order = new Order();

        orderService.process(order);

        InOrder inOrder = inOrder(inventoryService, paymentService);

        inOrder.verify(inventoryService).reserve(order);
        inOrder.verify(paymentService).charge(order);
    }
}

6. Using @Mock with JUnit 5

Instead of manually creating mocks with mock(), you can use Mockito’s JUnit 5 extension.

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

import static org.mockito.Mockito.verify;

@ExtendWith(MockitoExtension.class)
class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @InjectMocks
    private UserService userService;

    @Test
    void register_shouldSaveUser() {
        User user = new User();

        userService.register(user);

        verify(userRepository).save(user);
    }
}

Here:

@Mock
private UserRepository userRepository;

creates a mock repository.

@InjectMocks
private UserService userService;

creates the service and injects the mock into it.

7. Capturing Arguments with ArgumentCaptor

Use ArgumentCaptor when you want to inspect the object passed to a method.

import org.junit.jupiter.api.Test;
import org.mockito.ArgumentCaptor;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;

class UserServiceTest {

    @Test
    void register_shouldSaveUserWithExpectedName() {
        UserRepository userRepository = mock(UserRepository.class);
        UserService userService = new UserService(userRepository);

        userService.register("Alice");

        ArgumentCaptor<User> userCaptor = ArgumentCaptor.forClass(User.class);

        verify(userRepository).save(userCaptor.capture());

        User savedUser = userCaptor.getValue();

        assertEquals("Alice", savedUser.getName());
    }
}

This is useful when the method under test creates a new object internally, so you cannot verify using the exact same instance.

8. Verifying Exceptions Still Triggers Calls

You can combine JUnit assertions with Mockito verification.

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertThrows;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.verify;

class PaymentServiceTest {

    @Test
    void pay_invalidAmount_shouldLogFailure() {
        AuditLogger auditLogger = mock(AuditLogger.class);
        PaymentService paymentService = new PaymentService(auditLogger);

        assertThrows(IllegalArgumentException.class, () -> {
            paymentService.pay(-10);
        });

        verify(auditLogger).log("Invalid payment amount: -10");
    }
}

9. Maven Dependencies

For JUnit 5 and Mockito, add dependencies like these:

<dependencies>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>5.13.4</version>
        <scope>test</scope>
    </dependency>

    <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-core</artifactId>
        <version>5.18.0</version>
        <scope>test</scope>
    </dependency>

    <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-junit-jupiter</artifactId>
        <version>5.18.0</version>
        <scope>test</scope>
    </dependency>
</dependencies>

10. Gradle Dependencies

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter:5.13.4'
    testImplementation 'org.mockito:mockito-core:5.18.0'
    testImplementation 'org.mockito:mockito-junit-jupiter:5.18.0'

    testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
}

test {
    useJUnitPlatform()
}

Common Verification Patterns

verify(repository).save(user);
verify(repository, times(1)).save(user);
verify(repository, never()).delete(user);
verify(repository, atLeastOnce()).save(any(User.class));
verify(repository, atMost(3)).findByEmail(any(String.class));
verifyNoInteractions(repository);
verifyNoMoreInteractions(repository);

Summary

Use Mockito’s verify() when you want to test interactions between objects.

Typical usage:

verify(mock).method(argument);

For example:

verify(userRepository).save(user);

Use verification when the important result of a method is not just a returned value, but that another dependency was called correctly.

How do I use @Mock and @InjectMocks with JUnit?

To use @Mock and @InjectMocks with JUnit, you typically use them with Mockito.

  • @Mock creates a fake/mock dependency.
  • @InjectMocks creates the class under test and injects the mocks into it.
  • With JUnit 5, you enable Mockito using @ExtendWith(MockitoExtension.class).

1. Add Mockito dependencies

Maven

<dependencies>
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>5.11.4</version>
        <scope>test</scope>
    </dependency>

    <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-junit-jupiter</artifactId>
        <version>5.14.2</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Gradle

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter:5.11.4'
    testImplementation 'org.mockito:mockito-junit-jupiter:5.14.2'
}

test {
    useJUnitPlatform()
}

2. Example class to test

Suppose you have a service that depends on a repository:

public class UserService {
    private final UserRepository userRepository;

    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public String getUsernameById(Long id) {
        User user = userRepository.findById(id);

        if (user == null) {
            return "Unknown";
        }

        return user.getName();
    }
}

Repository:

public interface UserRepository {
    User findById(Long id);
}

Model:

public class User {
    private final Long id;
    private final String name;

    public User(Long id, String name) {
        this.id = id;
        this.name = name;
    }

    public Long getId() {
        return id;
    }

    public String getName() {
        return name;
    }
}

3. Use @Mock and @InjectMocks

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Mockito.when;

@ExtendWith(MockitoExtension.class)
class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @InjectMocks
    private UserService userService;

    @Test
    void getUsernameByIdReturnsUserNameWhenUserExists() {
        when(userRepository.findById(1L))
                .thenReturn(new User(1L, "Alice"));

        String result = userService.getUsernameById(1L);

        assertEquals("Alice", result);
    }

    @Test
    void getUsernameByIdReturnsUnknownWhenUserDoesNotExist() {
        when(userRepository.findById(99L))
                .thenReturn(null);

        String result = userService.getUsernameById(99L);

        assertEquals("Unknown", result);
    }
}

How it works

@Mock
private UserRepository userRepository;

This tells Mockito to create a mock implementation of UserRepository.

@InjectMocks
private UserService userService;

This tells Mockito to create a UserService instance and inject the mocked UserRepository into it.

Mockito tries injection in this order:

  1. Constructor injection
  2. Setter injection
  3. Field injection

Constructor injection is usually the best option because it makes dependencies explicit and easier to test.

Verifying mock interactions

You can also verify that a dependency method was called:

import static org.mockito.Mockito.verify;

@Test
void getUsernameByIdCallsRepository() {
    when(userRepository.findById(1L))
            .thenReturn(new User(1L, "Alice"));

    userService.getUsernameById(1L);

    verify(userRepository).findById(1L);
}

Common mistake: forgetting Mockito extension

If you forget this:

@ExtendWith(MockitoExtension.class)

then your @Mock fields may remain null, causing a NullPointerException.

JUnit 4 version

If you are using JUnit 4, use @RunWith(MockitoJUnitRunner.class) instead:

import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.MockitoJUnitRunner;

import static org.junit.Assert.assertEquals;
import static org.mockito.Mockito.when;

@RunWith(MockitoJUnitRunner.class)
public class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @InjectMocks
    private UserService userService;

    @Test
    public void getUsernameByIdReturnsUserNameWhenUserExists() {
        when(userRepository.findById(1L))
                .thenReturn(new User(1L, "Alice"));

        String result = userService.getUsernameById(1L);

        assertEquals("Alice", result);
    }
}

Quick summary

Use this pattern for JUnit 5:

@ExtendWith(MockitoExtension.class)
class MyServiceTest {

    @Mock
    private MyRepository repository;

    @InjectMocks
    private MyService service;

    @Test
    void testSomething() {
        when(repository.findSomething()).thenReturn("value");

        String result = service.doSomething();

        assertEquals("value", result);
    }
}

Use @Mock for dependencies and @InjectMocks for the class you are testing.

How do I mock dependencies in unit tests?

To mock dependencies in unit tests, you usually use a mocking framework such as Mockito. Mocking lets you test one class in isolation without running the real logic of its collaborators.

Basic Mockito Example

Suppose you have a service that depends on another class:

@Service
public class MyService {

    private final MyDependency dependency;

    public MyService(MyDependency dependency) {
        this.dependency = dependency;
    }

    public void process() {
        dependency.doSomething();
    }
}

You can mock MyDependency in a unit test like this:

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

import static org.mockito.Mockito.verify;

@ExtendWith(MockitoExtension.class)
class MyServiceTest {

    @Mock
    private MyDependency dependency;

    @InjectMocks
    private MyService myService;

    @Test
    void processCallsDependency() {
        myService.process();

        verify(dependency).doSomething();
    }
}

What the annotations mean

  • @Mock creates a mock object.
  • @InjectMocks creates the class under test and injects the mocks into it.
  • @ExtendWith(MockitoExtension.class) enables Mockito support in JUnit 5.
  • verify(...) checks that a method was called.

Mocking return values

If the dependency returns a value, use when(...).thenReturn(...):

import static org.mockito.Mockito.when;

when(repository.findNameById(1L)).thenReturn("Alice");

Example:

@Test
void returnsMockedValue() {
    when(userRepository.findNameById(1L)).thenReturn("Alice");

    String result = userService.getUserName(1L);

    assertEquals("Alice", result);
}

Mocking exceptions

You can also make a mock throw an exception:

import static org.mockito.Mockito.when;

when(repository.findById(99L))
        .thenThrow(new EntityNotFoundException("User not found"));

For void methods, use doThrow(...):

import static org.mockito.Mockito.doThrow;

doThrow(new RuntimeException("Failure"))
        .when(dependency)
        .doSomething();

Verifying interactions

You can verify how your class interacted with its dependencies:

verify(dependency).doSomething();
verify(dependency, times(1)).doSomething();
verify(dependency, never()).doSomething();

Spring Boot unit test example

For a pure unit test, prefer Mockito without starting the Spring context:

@ExtendWith(MockitoExtension.class)
class MyServiceTest {

    @Mock
    private MyDependency dependency;

    @InjectMocks
    private MyService service;

    @Test
    void processCallsDependency() {
        service.process();

        verify(dependency).doSomething();
    }
}

Spring integration-style test

If you need the Spring context, use Spring’s test support and replace a bean with a mock:

@SpringBootTest
class MyServiceSpringTest {

    @MockitoBean
    private MyDependency dependency;

    @Autowired
    private MyService service;

    @Test
    void processCallsDependency() {
        service.process();

        verify(dependency).doSomething();
    }
}

Use this style when you want to test Spring wiring, configuration, transactions, security, or other framework behavior.

Rule of thumb

  • Use Mockito @Mock + @InjectMocks for fast unit tests.
  • Use Spring test annotations only when you need the Spring application context.
  • Mock external systems such as databases, APIs, message queues, and file systems.
  • Avoid mocking simple value objects or the class you are actually testing.

How do I use Mockito with JUnit?

To use Mockito with JUnit, you add Mockito to your test dependencies, enable Mockito in your JUnit test class, then create mocks and define their behavior.

Below is a simple JUnit 5 + Mockito example.

1. Add Dependencies

Maven

<dependencies>
    <!-- JUnit 5 -->
    <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter</artifactId>
        <version>5.11.4</version>
        <scope>test</scope>
    </dependency>

    <!-- Mockito Core -->
    <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-core</artifactId>
        <version>5.14.2</version>
        <scope>test</scope>
    </dependency>

    <!-- Mockito integration for JUnit 5 -->
    <dependency>
        <groupId>org.mockito</groupId>
        <artifactId>mockito-junit-jupiter</artifactId>
        <version>5.14.2</version>
        <scope>test</scope>
    </dependency>
</dependencies>

Make sure your Maven Surefire plugin supports JUnit 5:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>3.5.2</version>
        </plugin>
    </plugins>
</build>

Gradle

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter:5.11.4'
    testImplementation 'org.mockito:mockito-core:5.14.2'
    testImplementation 'org.mockito:mockito-junit-jupiter:5.14.2'
}

test {
    useJUnitPlatform()
}

2. Example Class to Test

Suppose you have a service that depends on a repository.

public class User {
    private final Long id;
    private final String name;

    public User(Long id, String name) {
        this.id = id;
        this.name = name;
    }

    public Long getId() {
        return id;
    }

    public String getName() {
        return name;
    }
}
import java.util.Optional;

public interface UserRepository {
    Optional<User> findById(Long id);
}
public class UserService {
    private final UserRepository userRepository;

    public UserService(UserRepository userRepository) {
        this.userRepository = userRepository;
    }

    public String getUserName(Long id) {
        return userRepository.findById(id)
                .map(User::getName)
                .orElse("Unknown User");
    }
}

3. Write a Mockito Test with JUnit 5

Use @ExtendWith(MockitoExtension.class) to enable Mockito support.

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

import java.util.Optional;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Mockito.verify;
import static org.mockito.Mockito.when;

@ExtendWith(MockitoExtension.class)
class UserServiceTest {

    @Mock
    private UserRepository userRepository;

    @InjectMocks
    private UserService userService;

    @Test
    void shouldReturnUserNameWhenUserExists() {
        User user = new User(1L, "Alice");

        when(userRepository.findById(1L))
                .thenReturn(Optional.of(user));

        String result = userService.getUserName(1L);

        assertEquals("Alice", result);
        verify(userRepository).findById(1L);
    }

    @Test
    void shouldReturnUnknownUserWhenUserDoesNotExist() {
        when(userRepository.findById(99L))
                .thenReturn(Optional.empty());

        String result = userService.getUserName(99L);

        assertEquals("Unknown User", result);
        verify(userRepository).findById(99L);
    }
}

4. What the Mockito Annotations Mean

Annotation Purpose
@Mock Creates a mock object
@InjectMocks Creates the class under test and injects mocks into it
@ExtendWith(MockitoExtension.class) Enables Mockito support in JUnit 5

5. Common Mockito Methods

when(...).thenReturn(...)

Used to define mock behavior.

when(userRepository.findById(1L))
        .thenReturn(Optional.of(new User(1L, "Alice")));

verify(...)

Used to check whether a method was called.

verify(userRepository).findById(1L);

verify(..., times(...))

Used to check how many times a method was called.

verify(userRepository, times(1)).findById(1L);

You need this static import:

import static org.mockito.Mockito.times;

6. Mockito Without Annotations

You can also create mocks manually.

import org.junit.jupiter.api.Test;

import java.util.Optional;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

class UserServiceManualMockTest {

    @Test
    void shouldReturnUserName() {
        UserRepository userRepository = mock(UserRepository.class);
        UserService userService = new UserService(userRepository);

        when(userRepository.findById(1L))
                .thenReturn(Optional.of(new User(1L, "Alice")));

        String result = userService.getUserName(1L);

        assertEquals("Alice", result);
    }
}

7. Typical Mockito Test Structure

A clean Mockito test usually follows the Arrange, Act, Assert pattern:

@Test
void shouldReturnUserName() {
    // Arrange
    User user = new User(1L, "Alice");
    when(userRepository.findById(1L)).thenReturn(Optional.of(user));

    // Act
    String result = userService.getUserName(1L);

    // Assert
    assertEquals("Alice", result);
    verify(userRepository).findById(1L);
}

Summary

To use Mockito with JUnit 5:

  1. Add mockito-core and mockito-junit-jupiter.
  2. Add @ExtendWith(MockitoExtension.class) to your test class.
  3. Use @Mock for dependencies.
  4. Use @InjectMocks for the class being tested.
  5. Use when(...).thenReturn(...) to define behavior.
  6. Use verify(...) to check interactions.

How do I write tests for Java records?

Java records are compact classes designed to hold immutable data. Because records automatically provide a constructor, accessor methods, equals(), hashCode(), and toString(), testing them is usually simpler than testing ordinary classes.

In most cases, you do not need to test Java’s generated record behavior directly. Instead, test:

  • custom validation in the compact constructor
  • custom methods you add to the record
  • behavior that depends on equality or immutability
  • serialization/deserialization if the record is used with JSON or persistence frameworks

Example Record

Suppose you have this Java record:

public record User(String username, String email, int age) {

    public User {
        if (username == null || username.isBlank()) {
            throw new IllegalArgumentException("Username must not be blank");
        }

        if (email == null || !email.contains("@")) {
            throw new IllegalArgumentException("Email must be valid");
        }

        if (age < 0) {
            throw new IllegalArgumentException("Age must not be negative");
        }
    }

    public boolean isAdult() {
        return age >= 18;
    }
}

This record has:

  • three components: username, email, and age
  • validation in the compact constructor
  • a custom method named isAdult()

Basic JUnit 5 Test Class

Here is a simple JUnit 5 test class:

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.*;

class UserTest {

    @Test
    void shouldCreateUserWithValidData() {
        User user = new User("alice", "[email protected]", 25);

        assertEquals("alice", user.username());
        assertEquals("[email protected]", user.email());
        assertEquals(25, user.age());
    }

    @Test
    void shouldReturnTrueWhenUserIsAdult() {
        User user = new User("bob", "[email protected]", 20);

        assertTrue(user.isAdult());
    }

    @Test
    void shouldReturnFalseWhenUserIsNotAdult() {
        User user = new User("charlie", "[email protected]", 15);

        assertFalse(user.isAdult());
    }

    @Test
    void shouldRejectBlankUsername() {
        IllegalArgumentException exception = assertThrows(
                IllegalArgumentException.class,
                () -> new User("", "[email protected]", 25)
        );

        assertEquals("Username must not be blank", exception.getMessage());
    }

    @Test
    void shouldRejectInvalidEmail() {
        IllegalArgumentException exception = assertThrows(
                IllegalArgumentException.class,
                () -> new User("alice", "invalid-email", 25)
        );

        assertEquals("Email must be valid", exception.getMessage());
    }

    @Test
    void shouldRejectNegativeAge() {
        IllegalArgumentException exception = assertThrows(
                IllegalArgumentException.class,
                () -> new User("alice", "[email protected]", -1)
        );

        assertEquals("Age must not be negative", exception.getMessage());
    }
}

Testing Generated Accessor Methods

Record accessors use the component name directly. For example, if your record is:

public record Product(String name, double price) {
}

The accessors are:

product.name();
product.price();

not:

product.getName();
product.getPrice();

A basic test looks like this:

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;

class ProductTest {

    @Test
    void shouldExposeRecordComponents() {
        Product product = new Product("Keyboard", 49.99);

        assertEquals("Keyboard", product.name());
        assertEquals(49.99, product.price());
    }
}

However, for plain records with no validation or custom behavior, these tests often provide little value because they only verify Java-generated code.


Testing equals() and hashCode()

Records automatically generate equals() and hashCode() based on all record components.

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertNotEquals;

class ProductTest {

    @Test
    void shouldCompareRecordsByComponentValues() {
        Product first = new Product("Keyboard", 49.99);
        Product second = new Product("Keyboard", 49.99);
        Product third = new Product("Mouse", 19.99);

        assertEquals(first, second);
        assertEquals(first.hashCode(), second.hashCode());
        assertNotEquals(first, third);
    }
}

Again, you usually do not need this test unless your application depends heavily on equality behavior, such as using records as keys in a Map or elements in a Set.


Testing toString()

Records also generate a readable toString() method:

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.assertEquals;

class ProductTest {

    @Test
    void shouldGenerateReadableToString() {
        Product product = new Product("Keyboard", 49.99);

        assertEquals("Product[name=Keyboard, price=49.99]", product.toString());
    }
}

Be careful with this kind of test. It can be brittle because it depends on the exact string format.

Test toString() mainly when:

  • you override it
  • logs or messages depend on its output
  • the string representation is part of your expected behavior

Testing Constructor Validation

Records are commonly used with compact constructors for validation.

public record EmailAddress(String value) {

    public EmailAddress {
        if (value == null || value.isBlank()) {
            throw new IllegalArgumentException("Email must not be blank");
        }

        if (!value.contains("@")) {
            throw new IllegalArgumentException("Email must contain @");
        }
    }
}

Test both valid and invalid cases:

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.*;

class EmailAddressTest {

    @Test
    void shouldCreateEmailAddressWhenValueIsValid() {
        EmailAddress email = new EmailAddress("[email protected]");

        assertEquals("[email protected]", email.value());
    }

    @Test
    void shouldRejectNullEmail() {
        IllegalArgumentException exception = assertThrows(
                IllegalArgumentException.class,
                () -> new EmailAddress(null)
        );

        assertEquals("Email must not be blank", exception.getMessage());
    }

    @Test
    void shouldRejectBlankEmail() {
        IllegalArgumentException exception = assertThrows(
                IllegalArgumentException.class,
                () -> new EmailAddress(" ")
        );

        assertEquals("Email must not be blank", exception.getMessage());
    }

    @Test
    void shouldRejectEmailWithoutAtSign() {
        IllegalArgumentException exception = assertThrows(
                IllegalArgumentException.class,
                () -> new EmailAddress("invalid-email")
        );

        assertEquals("Email must contain @", exception.getMessage());
    }
}

Using Parameterized Tests for Records

Parameterized tests are useful when a record has multiple invalid input values.

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.ValueSource;

import static org.junit.jupiter.api.Assertions.assertThrows;

class EmailAddressTest {

    @ParameterizedTest
    @ValueSource(strings = {"", " ", "invalid-email", "user.example.com"})
    void shouldRejectInvalidEmailValues(String value) {
        assertThrows(
                IllegalArgumentException.class,
                () -> new EmailAddress(value)
        );
    }
}

For more complex data, use @CsvSource:

import org.junit.jupiter.params.ParameterizedTest;
import org.junit.jupiter.params.provider.CsvSource;

import static org.junit.jupiter.api.Assertions.assertThrows;

class UserTest {

    @ParameterizedTest
    @CsvSource({
            "'', [email protected], 25",
            "' ', [email protected], 25",
            "alice, invalid-email, 25",
            "alice, [email protected], -1"
    })
    void shouldRejectInvalidUserData(String username, String email, int age) {
        assertThrows(
                IllegalArgumentException.class,
                () -> new User(username, email, age)
        );
    }
}

Testing Custom Methods in Records

If your record contains business logic, test that logic directly.

public record Money(String currency, int amount) {

    public boolean isPositive() {
        return amount > 0;
    }

    public Money add(Money other) {
        if (!currency.equals(other.currency())) {
            throw new IllegalArgumentException("Currencies must match");
        }

        return new Money(currency, amount + other.amount());
    }
}

Tests:

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.*;

class MoneyTest {

    @Test
    void shouldReturnTrueForPositiveAmount() {
        Money money = new Money("USD", 100);

        assertTrue(money.isPositive());
    }

    @Test
    void shouldAddMoneyWithSameCurrency() {
        Money first = new Money("USD", 100);
        Money second = new Money("USD", 50);

        Money result = first.add(second);

        assertEquals(new Money("USD", 150), result);
    }

    @Test
    void shouldRejectAddingDifferentCurrencies() {
        Money first = new Money("USD", 100);
        Money second = new Money("EUR", 50);

        IllegalArgumentException exception = assertThrows(
                IllegalArgumentException.class,
                () -> first.add(second)
        );

        assertEquals("Currencies must match", exception.getMessage());
    }
}

Testing Immutability

Records are shallowly immutable. This means record components cannot be reassigned, but if a component refers to a mutable object, that object can still be changed.

Example:

import java.util.List;

public record Order(List<String> items) {
}

This record is not deeply immutable:

import java.util.ArrayList;
import java.util.List;

Order order = new Order(new ArrayList<>(List.of("Book")));
order.items().add("Pen");

To make it safer, copy the list:

import java.util.List;

public record Order(List<String> items) {

    public Order {
        items = List.copyOf(items);
    }
}

Then test it:

import org.junit.jupiter.api.Test;

import java.util.ArrayList;
import java.util.List;

import static org.junit.jupiter.api.Assertions.*;

class OrderTest {

    @Test
    void shouldDefensivelyCopyItems() {
        List<String> items = new ArrayList<>();
        items.add("Book");

        Order order = new Order(items);

        items.add("Pen");

        assertEquals(List.of("Book"), order.items());
    }

    @Test
    void shouldExposeUnmodifiableItems() {
        Order order = new Order(new ArrayList<>(List.of("Book")));

        assertThrows(
                UnsupportedOperationException.class,
                () -> order.items().add("Pen")
        );
    }
}

This is a valuable test because it verifies your own defensive-copying behavior, not just Java-generated record behavior.


What Should You Actually Test?

For Java records, focus your tests on behavior you wrote yourself.

Good things to test:

Feature Should You Test It? Why
Accessor methods Usually no Generated by Java
equals() / hashCode() Sometimes Useful if equality is important in your domain
toString() Rarely Usually generated and brittle to assert
Compact constructor validation Yes This is your logic
Custom methods Yes This is your logic
Defensive copying Yes Important for immutability
Serialization/deserialization Yes, if used Important for APIs and persistence

Recommended Testing Style

Use clear test names:

@Test
void shouldRejectNegativeAge() {
    // test body
}

Follow the Arrange-Act-Assert pattern:

@Test
void shouldCreateUserWithValidData() {
    // Arrange
    String username = "alice";
    String email = "[email protected]";
    int age = 25;

    // Act
    User user = new User(username, email, age);

    // Assert
    assertEquals(username, user.username());
    assertEquals(email, user.email());
    assertEquals(age, user.age());
}

Summary

To test Java records:

  1. Do not over-test generated code.
  2. Test constructor validation.
  3. Test custom methods.
  4. Test defensive copying for mutable components.
  5. Test JSON or persistence integration only when records are used that way.
  6. Use JUnit 5 assertions such as assertEquals(), assertTrue(), assertFalse(), and assertThrows().

A plain record like this usually needs no dedicated unit test:

public record Point(int x, int y) {
}

But a record like this should be tested:

public record Age(int value) {

    public Age {
        if (value < 0) {
            throw new IllegalArgumentException("Age must not be negative");
        }
    }

    public boolean isAdult() {
        return value >= 18;
    }
}

Because it contains behavior that belongs to your application, not just Java’s generated record features.