giuseppe-trisciuoglio/developer-kit

unit-test-service-layer

Provides patterns for unit testing service layer with Mockito.

소스 보기
원본 Skill 문서

원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.

Unit Testing Service Layer with Mockito

Overview

Provides patterns for unit testing @Service classes using Mockito. Mocks repository calls, verifies method invocations, tests exception scenarios, and stubs external API responses. Enables fast, isolated tests without Spring container or database.

When to Use

  • Testing business logic in @Service classes
  • Mocking repository and external client dependencies
  • Verifying service interactions with mocked collaborators
  • Testing error handling and edge cases in services
  • Writing fast, isolated unit tests (no database, no API calls)

Instructions

Follow this workflow to test service layer with Mockito, including validation checkpoints:

1. Setup Test Class

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

2. Declare Mocks with @Mock and @InjectMocks

Use @Mock for dependencies (repositories, clients) and @InjectMocks for the service under test.

3. Arrange-Act-Assert with Validation

Arrange: Create test data and configure mock return values using when().thenReturn().

Act: Execute the service method being tested.

Assert:

  • Verify returned values with AssertJ assertions
  • Verify mock interactions with verify()
  • Validation checkpoint: Run test and confirm green bar

4. Test Exception Scenarios

Configure mocks to throw exceptions with when().thenThrow().

Validation checkpoint: Verify exception type and message

5. Verify Complete Coverage

  • Run full test suite: mvn test or gradle test
  • Check coverage report: mvn test jacoco:report
  • Validation checkpoint: Confirm all service methods have corresponding tests

Examples

Basic Service Test Pattern

java
@ExtendWith(MockitoExtension.class)
class UserServiceTest {

  @Mock
  private UserRepository userRepository;

  @InjectMocks
  private UserService userService;

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

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

    // Assert
    assertThat(result.getName()).isEqualTo("Alice");
    verify(userRepository).findById(1L);
  }

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

    // Act & Assert
    assertThatThrownBy(() -> userService.getUser(999L))
      .isInstanceOf(UserNotFoundException.class);
  }
}

Verify Method Invocations

java
@Test
void shouldSendEmailOnUserCreation() {
  User newUser = new User(1L, "Alice", "alice@example.com");
  when(userRepository.save(any(User.class))).thenReturn(newUser);

  enrichmentService.registerNewUser("Alice", "alice@example.com");

  verify(userRepository).save(any(User.class));
  verify(emailService).sendWelcomeEmail("alice@example.com");
}

For additional patterns (multiple dependencies, argument captors, async services, InOrder verification), see references/examples.md.

Best Practices

  • Use `@ExtendWith(MockitoExtension.class)` for JUnit 5 integration
  • Mock only direct dependencies of the service under test
  • Verify interactions to ensure correct collaboration
  • Test one behavior per test method - keep tests focused
  • Use descriptive variable names: expectedUser, actualUser, captor
  • Create real instances for value objects and DTOs (don't mock them)

Constraints and Warnings

  • Do not mock value objects or DTOs; create real instances with test data.
  • Avoid mocking too many dependencies; consider refactoring if a service has too many collaborators.
  • Tests must be independent; do not rely on execution order.
  • Be cautious with @Spy; partial mocking is harder to understand and maintain.
  • Do not test private methods directly; test them through public method behavior.
  • Argument matchers (any(), eq()) cannot be mixed with actual values in the same stub.
  • Avoid over-verifying; verify only interactions important to the test scenario.

References

같은 저장소의 Skills

더 많은 Skills

모든 Skills
giuseppe-trisciuoglio
커뮤니티

clean-architecture

Provides implementation patterns for Clean Architecture, Hexagonal Architecture (Ports & Adapters), and Domain-Driven Design in PHP 8.3+ with Symfony 7.x. Use when architecting enterprise PHP applications with entities/value objects/aggregates, refactoring legacy code to modern patterns, implementing domain-driven design with Symfony, or creating testable backends with clear separation of concerns.

설치 수
4
GitHub Stars
359
업데이트
9월 10일
giuseppe-trisciuoglio
커뮤니티

nextjs-authentication

Provides authentication implementation patterns for Next.js 15+ App Router using Auth.js 5 (NextAuth.js). Use when setting up authentication flows, implementing protected routes, managing sessions in Server Components and Server Actions, configuring OAuth providers, implementing role-based access control, or handling sign-in/sign-out flows in Next.js applications.

설치 수
2
GitHub Stars
358
업데이트
9월 10일
giuseppe-trisciuoglio
커뮤니티

adr-drafting

Creates new Architecture Decision Record (ADR) documents for significant architectural changes using a consistent template and repository-aware naming and storage guidance. Use when a user or agent decides on an architectural change, needs to document technical rationale, or wants to add a new ADR to the project history.

설치 수
1
GitHub Stars
358
업데이트
9월 10일
giuseppe-trisciuoglio
커뮤니티

dynamodb-toolbox-patterns

Provides TypeScript patterns for DynamoDB-Toolbox v2 including schema/table/entity modeling, .build() command workflow, query/scan access patterns, batch and transaction operations, and single-table design with computed keys. Use when implementing type-safe DynamoDB access layers with DynamoDB-Toolbox v2 in TypeScript services or serverless applications.

설치 수
1
GitHub Stars
358
업데이트
9월 10일