JUnit 단위 테스트 적용, JaCoCo 커버리지 측정

📌 목차

1. JUnit이란?
2. JUnit 적용 방법
3. JUnit 적용 예시
4. DB 연동 단위 테스트 방법
5. 테스트 실행
6. 테스트 커버리지란?
7. 테스트 커버리지 측정 방법 - JaCoCo
8. 한글 경로 문제 해결 방법
9. 테스트 결과 확인
   
   

🎯 0.JUnit 단위 테스트 적용하기

기존 테스트 코드를 작성하지 않고 직접 프로그램을 로컬에서 실행해서 테스트하고 있었다.

 => 코드 변경 시 마다 기능을 재테스트 하는데 시간이 소요되고, 테스터가 놓치는 부분이 있을 수 있음.

이를 개선하기 위해 JUnit 기본 사용법을 알아보고 ‘일정 시스템’에 적용해보기로 했다!!

 

📌 1. JUnit이란?

• Java에서 가장 많이 쓰이는 단위 테스트 프레임워크
• 역할: 테스트 작성 → 자동 실행 → 결과 확인
• Spring Boot에서는 spring-boot-starter-test에 JUnit 5, Mockito가 포함되어 있다!!
  
  

📖 pom.xml

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
</dependency>

        <!-- <dependency>
            <groupId>org.junit.jupiter</groupId>
            <artifactId>junit-jupiter</artifactId>
            <scope>test</scope>
        </dependency> -->

        <!-- Mockito -->
        <!-- <dependency>
            <groupId>org.mockito</groupId>
            <artifactId>mockito-core</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.mockito</groupId>
            <artifactId>mockito-junit-jupiter</artifactId>
            <scope>test</scope>
        </dependency> -->

 

✅ 기본 사용법

• 테스트 클래스: src/test/java
• 테스트 메서드: @Test 붙임

📖 예제

@SpringBootTest
class MyServiceTest {

    @Autowired
    MyService myService;

    @Test
    void testAdd() {
        int result = myService.add(2, 3);
        assertEquals(5, result);
    }
}

 

📌 2.  JUnit 적용 방법

✅ 2-1. 테스트 클래스 선택

🔹기본 원칙: 보통 하나의 클래스 → 하나의 테스트 클래스

📖 예: ScheduleServiceImpl.java → ScheduleServiceImplTest.java

🔹규칙

• 테스트 클래스 이름은 보통 원본 클래스 이름 + Test
• 패키지 구조는 원본 클래스와 같은 패키지에 두면 private 메서드 테스트나 package-private 접근이 편함

📖 예

src/main/java/kr/co/calender/service/ScheduleServiceImpl.java

src/test/java/kr/co/calender/service/ScheduleServiceImplTest.java

🔹예외

• 여러 관련 기능을 묶어서 통합 테스트를 하고 싶으면 → 한 파일에 여러 클래스를 테스트할 수도 있음
• 반대로 단순 helper 유틸이라면 → 여러 유틸을 한 테스트 파일에서 다뤄도 됨
  
  

🔹 🚀 결론

대부분은 1:1 매칭, 필요시 통합 테스트용 파일 따로 생성

 

✅ 2-2. 테스트할 메서드 선택

🔹공개(Public) 메서드 위주로 테스트

• Controller → API 호출 결과 검증
• Service → 핵심 로직(계산, 상태 변경, 예외 처리) 검증
  
  

🔹private 메서드

• 일반적으로 직접 테스트하지 않고 public 메서드를 통해 간접 테스트
• 예외: 꼭 필요하면 Reflection으로 호출 가능(Method.invoke())
  
  

✅ 2-3. given-when-then 패턴

• given-when-then 패턴 (BDD – Behavior Driven Development 스타일)
• 테스트 코드에서 조건 → 실행 → 결과를 구분해 가독성을 높이는 패턴

1️⃣ Given : 테스트 준비 (입력값, Mock 동작 설정)

2️⃣ When : 실제 테스트 대상 메서드 호출

3️⃣ Then : 실행 결과 검증 (assert, verify)

 

📖 예시

@Test
@DisplayName("주문 생성 성공")
void placeOrder_success() {
    // Given (상태/Mock 준비)  
    when(orderRepository.save(any())).thenReturn(new Order(1L));

    // When (메서드 실행)
    Order saved = orderService.placeOrder(new CreateOrderCmd(...));

    // Then (검증)
    assertThat(saved.getId()).isEqualTo(1L);
    verify(orderRepository, times(1)).save(any());
}

 

 

✅ 2-4. 자주 쓰는 JUnit 어노테이션

어노테이션	용도
@Test	테스트 메서드 지정
@BeforeEach	각 테스트 실행 전마다 초기화 작업 수행
@AfterEach	각 테스트 실행 후마다 정리 작업 수행
@BeforeAll	테스트 클래스 시작 전 한 번 실행 (static)
@AfterAll	테스트 클래스 종료 후 한 번 실행 (static)
@Disabled	특정 테스트 임시로 제외
@DisplayName("설명")	테스트 이름에 설명 추가 가능

 

 

✅ 2-5. Mock 객체 사용

🔍 2-5-1. Mock이란?

• 가짜 협력자 객체
• 호출 시 반환값을 지정할 수 있고, 호출 여부/횟수/파라미터를 검증할 수 있음

 

🔍 2-5-2. Mockito란?

• 가장 많이 쓰이는 자바 Mocking 프레임워크
• 테스트 대상 클래스의 협력 객체를 가짜(Mock)로 생성하고, 동작을 정의하거나 호출을 검증할 수 있게 해줌
• JUnit과 함께 쓰면 단위 테스트 작성이 훨씬 간단해짐

📖 예제

// Mock 생성
UserRepository repo = mock(UserRepository.class);

// 행동 정의 (Stub)
when(repo.findById(1L)).thenReturn(new User(1L, "홍길동"));

// 호출 & 결과 검증
verify(repo).findById(1L);
assertEquals(3, result.getUsersList().size());

 

📖 *BDD 스타일 (BDDMockito) - when과 동일 기능, 다른 스타일

given(repo.findById(1L)).willReturn(new User(1L, "홍길동"));

🔹2-5-3. @MockBean vs @Mock vs @InjectMocks

• @Mock: 가짜 객체를 만들어 반환해주는 어노테이션 -> 테스트 대상 내부에서 사용하는 클래스
• @Spy: Stub하지 않은 메소드들은 원본 메소드 그대로 사용하는 어노테이션
• @InjectMocks: 테스트 대상 클래스 생성 및 Mock(Mock/Spy로 생성된 가짜 객체) 주입  -> 테스트 대상 클래스

• *@MockBean : Spring 컨텍스트에서 실제 Bean 대체 (Spring boot 환경, 통합 테스트용)

💡 팁

• @InjectMocks → 구현체 대상으로만 테스트 (인터페이스는 로직 없음)
• @MockBean → 인터페이스 타입으로 등록하는 게 일반적

 

🔹 2-4-4. 언제 뭘 쓰지?

📖 서비스 단위 테스트 (Repository만 Mock)

서비스 메서드 내에서 실행되는 Repository, Mapper를 Mock으로 등록, .thenReturn()으로 값지정하여 실제 DB호출 없이 테스트한다.

-> @Mock 어노테이션을 통해 가짜 UserRepository를 만들고, @InjectMocks를 통해 User Service 에 이를 주입

@ExtendWith(MockitoExtension.class)
class OrderServiceTest {
    @Mock private OrderRepository orderRepository; // 컨텍스트 등록 X
    @InjectMocks private OrderServiceImpl orderService; // 테스트 대상
    
    @Test
    void placeOrder_success() {
        when(orderRepository.save(any())).thenReturn(new Order(1L));
        Order saved = orderService.placeOrder(new CreateOrderCmd(...));
        assertThat(saved.getId()).isEqualTo(1L);
        verify(orderRepository, times(1)).save(any());
    }
}

• 빠름, 스프링 안 띄움 → 순수 비즈니스 로직 검증에 최적.
  
  

📖 컨트롤러 슬라이스 테스트 (서비스만 Mock) → @WebMvcTest + @MockBean

@WebMvcTest(OrderController.class)
class OrderControllerTest {
    @Autowired private MockMvc mvc;
    @MockBean private OrderService orderService; // 컨텍스트에 "서비스 빈"으로 등록 & 실제 빈 대체

    @Test
    void getOrder_returns200() throws Exception {
        when(orderService.get(1L)).thenReturn(new OrderDto(1L, "OK"));
        mvc.perform(get("/orders/1"))
           .andExpect(status().isOk())
           .andExpect(jsonPath("$.id").value(1L));
        verify(orderService).get(1L);
    }
}

• MVC 빈만 로딩 → 컨트롤러-서비스 경계 검증에 적합

 

✅ 2-5. Assert 사용

JUnit에서 검증(assertion) 용도로 사용

• assertEquals(expected, actual) : 값 비교
• assertNotNull(object) : null 여부 확인
• assertTrue(condition) : 조건 true 확인
• assertFalse(condition) : 조건 false 확인
• assertThrows(Exception.class, () -> method()) : 예외 발생 검증
• assertAll(executables...) : 모든 assertion을 실행, 일부 실패해도 나머지 assertion 실행
  

assertAll(
    () -> assertEquals(1, result),
    () -> assertNotNull(obj),
    () -> verify(scheduleMapper).selectSchedule("SCHD001"),
);

 

 

✅ 2-6. verify 

• 해당 Mock 객체의 특정 메서드가 실제로 호출됐는지 확인

📖 기본 사용

verify(scheduleMapper).updateSchedule(any(ScheduleDTO.class));

 

📖 횟수 제어

• times(n) : n번 호출됐는지 확인
• never() : 호출되지 않았는지 확인
• atLeast(n) / atMost(n) : 최소/최대 호출 횟수 확인

verify(scheduleMapper, times(1)).updateSchedule(any());
verify(scheduleMapper, never()).deleteScheduleSharedUsers("SCHD002");
verify(scheduleMapper, atLeast(2)).insertScheduleSharedUser(any());
verify(scheduleMapper, atMost(3)).selectSchedule("SCHD001");

 

📖 순서 제어 (InOrder)

InOrder inOrder = inOrder(scheduleMapper);
inOrder.verify(scheduleMapper).selectSchedule("SCHD001");
inOrder.verify(scheduleMapper).deleteScheduleSharedUsers("SCHD001");
inOrder.verify(scheduleMapper).insertScheduleSharedUser(any());

 

✅ 2-6. Reflection 사용 (private 메서드 테스트)

• 보통은 public 메서드를 통해 간접 검증하는 게 원칙
• 꼭 필요할 때만 사용

Method privateMethod = MyService.class.getDeclaredMethod("privateCalculate", int.class);
privateMethod.setAccessible(true); // 접근 제한 해제
int result = (int) privateMethod.invoke(myService, 10); // 메서드 호출
assertEquals(20, result);

 

 

📌 3. JUnit 적용 예시

💡 Tip

• 핵심 로직, 예외 처리, 분기(if/else) 위주로 테스트
• 커버리지 수치를 높이는 것보다 실제 로직 검증이 더 중요
• DB 연동은 Mock 또는 인메모리 DB를 활용

✅ 3-1. Controller/Service 테스트

• Spring Boot 테스트 환경에서 호출 테스트 가능
  

// 1️⃣ Spring Boot 테스트 환경에서 Controller를 테스트할 때 사용
// webEnvironment = RANDOM_PORT : 실제 서버 포트가 랜덤으로 할당되어 테스트 간 충돌 방지
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)

// 2️⃣ MockMvc를 자동 설정해서 HTTP 요청/응답을 테스트할 수 있게 함
@AutoConfigureMockMvc

// 3️⃣ 테스트용 Security 설정을 불러와서 인증/인가 문제 없이 테스트 가능
@Import(TestSecurityConfig.class)
class ScheduleRestControllerTest {

    // 4️⃣ MockMvc 객체 주입 → Controller 요청 테스트용
    @Autowired
    private MockMvc mockMvc;

    // 5️⃣ 실제 Service 호출을 Mock 처리 → DB나 다른 의존성 영향 없이 테스트 가능
    @MockBean
    private ScheduleService scheduleService;

    // 6️⃣ 테스트 시작 전 초기화 작업
    @BeforeEach
    void setUp() {
        // 예: Mock 반환값 설정
        List<ScheduleDTO> mockSchedules = new ArrayList<>();
        mockSchedules.add(new ScheduleDTO("2025-08-18", "테스트 일정"));

        // scheduleService.getSchedules() 호출 시 mockSchedules 반환
        Mockito.when(scheduleService.getSchedules()).thenReturn(mockSchedules);
    }

    // 7️⃣ 실제 API 호출 테스트
    @Test
    void testGetSchedules() throws Exception {
        mockMvc.perform(get("/api/schedules")) // GET 요청 수행
               .andExpect(status().isOk())   // HTTP 상태 200 OK 확인
               .andExpect(jsonPath("$").isArray()) // JSON 배열 형식인지 확인
               .andExpect(jsonPath("$[0].title").value("테스트 일정")); // 첫 번째 요소 제목 확인
    }

}

이렇게 하면 Controller → Service → Repository 호출 흐름을 전체적으로 테스트 가능

 

✅ 3-2. Spring Security 테스트

• 운영 환경에서는 Security 때문에 테스트 실패 가능 → 단위 테스트용 SecurityConfig 추가
  

@TestConfiguration
@EnableWebSecurity
public class TestSecurityConfig {
    @Bean
    public SecurityFilterChain testFilterChain(HttpSecurity http) throws Exception {
        http
            .csrf(csrf -> csrf.disable())
            .authorizeHttpRequests(auth -> auth
                .anyRequest().permitAll()
            );
        return http.build();
    }
}

• 테스트 시 Security를 완전히 우회 → MockMvc로 Controller 테스트 가능
  
  

✅ 3-3. Private 메서드 테스트

• 보통 Private 메서드는 직접 테스트하지 않고 public 메서드 호출 시 간접 테스트
• 단, 핵심 로직이 private이면 Reflection으로 테스트 가능

📖 핵심 로직 판단 예시 - 어떤 메서드를 테스트하는 게 좋을까❓

메서드	테스트 필요성	이유
generateRepeatedSchedules	⭐⭐⭐⭐⭐ (필수)	반복 주기별 날짜 계산이 달라서 버그 가능성 큼. 원본일정 처리와 잘못된 종료일 처리 테스트 필요. (종료일이 시작일 이전일 때 등)
isRepeatStructureChanged	⭐⭐⭐⭐ (중요)	기존 일정 수정 시 반복 그룹 재생성 여부 판단 → 잘못되면 불필요하게 그룹 깨지거나 업데이트 누락됨.
copyScheduleProperties	⭐ (낮음)	단순 속성 복사. 일반적으로 getter/setter 단위는 테스트 가치 낮음. 대신 스프링 BeanUtils 같은 표준 유틸 쓰면 아예 테스트 필요 없음.

📖 예시 (Reflection 사용)

@Test
void testGenerateRepeatedSchedules() throws Exception {
    Method method = ScheduleService.class.getDeclaredMethod("generateRepeatedSchedules", ScheduleDTO.class);
    method.setAccessible(true);
    
    ScheduleDTO schedule = new ScheduleDTO();
    
    // schedule 초기화
    List<ScheduleDTO> result = (List<ScheduleDTO>) method.invoke(scheduleService, schedule);

    assertNotNull(result);
    assertFalse(result.isEmpty());
}

 

📌 4. DB 연동 단위 테스트

✅ 4-1. 목적

• DB 데이터를 바꾸는 함수 정확성 확인
• 실제 호출 경로 테스트 → 커버리지 확보
• 운영 DB 건드리지 않고 안전하게 테스트
  
  

✅ 4-2. 방법

• 인메모리 DB 사용 (H2 등)
• 트랜잭션 롤백

@Transactional
@Test
void testDBUpdate() { ... }

 

• Mocking (DB 호출 자체를 Mock)

 

📌 5. 테스트 실행

✅  # 클래스 전체 실행

mvn test

mvn test -Dtest=ScheduleServiceTest (test까지만 쳐도 디폴트)

 

✅  # 특정 메서드만 실행

mvn test -Dtest=ScheduleServiceTest#testUpdateSchedule_RepeatStructureChanged

 

📌 6. 테스트 커버리지란?

• 테스트 실행 시 코드가 얼마나 실행되었는지 비율로 나타낸 지표
  
  

✅ 종류

• 라인(Line) 커버리지: 몇 줄 실행됐는지
• 브랜치(Branch) 커버리지: if/else, switch 분기 실행 여부
• 조건(Condition) 커버리지: 조건식 true/false 케이스
  
  

💡 실제 현업에서는?

1. 커버리지 측정 도구 (JaCoCo, IntelliJ built-in, SonarQube) 로 리포트를 생성
2. CI/CD 파이프라인에 커버리지 검증을 걸어둠
3. 핵심 비즈니스 로직, 예외 처리, 분기를 중점적으로 테스트
4. 커버리지 수치보다는 테스트 케이스의 시나리오 완성도를 더 중시 (테스트가 진짜 버그를 잡을 수 있나?)

 

📌 7. 커버리지 측정 방법 - JaCoCo

🔍 7-1. JaCoCo 에이전트란?

• JVM에서 실행되는 작은 프로그램(JAR)
• Java 애플리케이션이 실행되는 동안 어떤 코드가 실행됐는지 추적(track)하는 역할
• 테스트 실행 시 코드 실행 정보 기록 → jacoco.exec 생성 → 리포트 변환 가능

 

❓어떻게 동작할까?

1️⃣ Maven에서 jacoco-maven-plugin이 prepare-agent 목표(goal)를 실행

2️⃣ JVM 옵션에 자동으로 붙음: -javaagent:"path/to/jacocoagent.jar=destfile=target/jacoco.exec"

3️⃣ JVM이 코드 실행할 때 모든 클래스의 실행 정보를 에이전트가 가로채서 기록

4️⃣ 테스트 종료 후 jacoco.exec 파일에 기록 저장

5️⃣ jacoco:report 실행하면 .exec 파일 → HTML/CSV 등 리포트로 변환

✅ 7-2. 설정 방법

📖 Maven 설정

<plugin>
  <groupId>org.jacoco</groupId>
  <artifactId>jacoco-maven-plugin</artifactId>
  <version>0.8.8</version>
  <executions>
    <execution>
      <goals><goal>prepare-agent</goal></goals>
    </execution>
    <execution>
      <id>report</id>
      <phase>verify</phase>
      <goals><goal>report</goal></goals>
    </execution>
  </executions>
</plugin>

 

✅ 7-3. 실행 방법

🔹단순 테스트 + 커버리지 확인: mvn clean test jacoco:report

🔹테스트 + 확장 검증: mvn clean test verify

• clean → target/ 폴더 삭제
• test → src/test/java 단위 테스트 실행
• jacoco:report → 테스트 결과 기반으로 JaCoCo 커버리지 리포트 생성
• verify → 테스트 후 추가 검증 단계 실행

 

🚨 8. 실행 오류 - 한글 경로, jdk버전 (CMD에서 실행)

✅ 8-1. 경로 문제

IDE내에서 실행 시 한글 경로 인식 못 함.

🔹 원인

IDE 단위 실행 → Maven 개입 X → JaCoCo 옵션 적용 안 됨 → .exec 파일 생성 실패

🔹 해결

1. Maven Surefire 임시경로 지정: argLine + JaCoCo destFile 지정
2. 임시 폴더 영문 경로 생성 및 Cmd에서 실행
   

1️⃣ pom.xml 설정

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <version>3.1.2</version>
  <configuration>
    <argLine>-javaagent:C:/Temp/.m2/org/jacoco/org.jacoco.agent/0.8.8/org.jacoco.agent-0.8.8-runtime.jar=destfile=C:/Temp/TestMvn/jacoco.exec</argLine>
  </configuration>
</plugin>

<plugin>
  <groupId>org.jacoco</groupId>
  <artifactId>jacoco-maven-plugin</artifactId>
  <version>0.8.8</version>
  <configuration>
    <destFile>C:/Temp/jacoco.exec</destFile>
    <dataFile>C:/Temp/jacoco.exec</dataFile>
    <outputDirectory>${project.build.directory}/jacoco-report</outputDirectory>                    
  </configuration>
</plugin>

 

2️⃣ 임시 디렉토리 세팅 및 cmd 명령

• 프로젝트 루트 경로에서 실행

set MAVEN_OPTS=-Dmaven.repo.local=C:\Temp\.m2
set JAVA_TOOL_OPTIONS=-Duser.home=C:\Temp\javahome
mvn clean test jacoco:report

✔️ cmd 닫으면 사라지는 임시 설정

❌ 단점: 기존 .m2 캐시는 못 쓰고, 임시 폴더에 새로 다운로드됨 (커스텀라이브러리?는 직접 새로 생성한 .m2 밑에 복사해야함. 파일명도 버전 붙여서!!

• 커스텀 라이브러리 설정: C:\Temp\.m2\local\lib\MessageCalendarAseUtil\1.0\MessageCalendarAseUtil-1.0.jar

    <!-- MessageCalendarAseUtil -->
    <dependency>
        <groupId>local.lib</groupId>
        <artifactId>MessageCalendarAseUtil</artifactId>
        <version>1.0</version>
    </dependency>

 

✅ 7-2. JDK 버전 문제

PC에 jdk8, jdk17 있고 프로젝트마다 다른 버전 이용. 기본 8.

해당 프로젝트는 IDE내에서 17사용하도록 설정해서 이용했었음.

 

🔹원인

• 메이븐 JDK 버전 
• mvn -v  입력 시 출력

Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)

Maven home: C:\Program Files\Apache\Maven\apache-maven-3.9.9

Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk1.8.0_202\jre

Default locale: ko_KR, platform encoding: MS949

OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"

🔹해결

set JAVA_HOME=C:\Program Files\Java\jdk-17
set PATH=%JAVA_HOME%\bin;%PATH%

 

🔹수정 후

• mvn -v 입력 시 출력

Picked up JAVA_TOOL_OPTIONS: -Duser.home=C:\Temp\TestMvn\javahome

Apache Maven 3.9.9 (8e8579a9e76f7d015ee5ec7bfcdc97d260186937)

Maven home: C:\Program Files\Apache\Maven\apache-maven-3.9.9

Java version: 17.0.13, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk-17

Default locale: ko_KR, platform encoding: MS949

OS name: "windows 11", version: "10.0", arch: "amd64", family: "windows"

 

📌8. 테스트 결과

✅ 8-1. 테스트 결과 확인

🔹파일별 테스트 결과 + 전체 결과

[INFO] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.97 s -- in kr.co.example.calender.controller.ScheduleRestControllerTest

[INFO] Running kr.co. example.calender.service.ScheduleServicePrivateTest

[INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.395 s -- in kr.co.example.calender.service.ScheduleServicePrivateTest

[INFO] Running kr.co.example.calender.service.ScheduleServiceTest

[INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.052 s -- in kr.co.example.calender.service.ScheduleServiceTest

[INFO]

[INFO] Results:

[INFO]

[INFO] Tests run: 22, Failures: 0, Errors: 0, Skipped: 0

[INFO]

[INFO]

[INFO] --- jacoco:0.8.8:report (default-cli) @ calendar ---

[INFO] Loading execution data file C:\Temp\TestMvn\jacoco.exec

[INFO] Analyzed bundle 'calendar' with 48 classes

[INFO] ------------------------------------------------------------------------

[INFO] BUILD SUCCESS

[INFO] ------------------------------------------------------------------------

[INFO] Total time:  01:14 min

[INFO] Finished at: 2025-08-18T11:27:50+09:00

[INFO] ------------------------------------------------------------------------

 

 

✅ 8-2. 커버리지 리포트 확인

🔹 생성위치: Calendar\target\jacoco-report\index.html

🔹 브라우저에서 오픈

디렉토리 -> 클래스 -> 메서드 -> 코드 라인 실행 유무 확인 가능

 

🚀 후기

🔹 주요 로직 테스트

주요 로직은 ScheduleService이어서, 이 서비스 위주로 테스트 코드를 작성했다.

 

🔹 조건별 테스트 작성과 오류 경험

위에서 JUnit에 대해 공부하며 기본 데이터만으로 테스트했을 때 서비스 커버리지는 약 5%였는데, 추가로 조건문 케이스별로 테스트 함수를 작성해봤다.

예를 들어, "일정 수정 함수 - 반복 일정 수정" 케이스를 테스트를 아래와 같이 작성.

   @Test
    @DisplayName("일정 수정 성공 테스트 - 반복 구조 변경 시 삭제 후 재생성")
    void testUpdateSchedule_RepeatStructureChanged() {
        // Given
        ScheduleDTO updateSchedule = new ScheduleDTO();
        BeanUtils.copyProperties(testSchedule, updateSchedule); // Spring BeanUtils 사용
        updateSchedule.setSchdTitle("수정된 일정");
        updateSchedule.setModifierId("USER001");
        updateSchedule.setUpdateMode("CURRENT");

        // 반복 구조 변경
        updateSchedule.setReptTypeCd("WEEKLY");
        updateSchedule.setBeginDate("2024-02-15");
        updateSchedule.setReptFinDate("2024-03-10");

        when(scheduleMapper.selectSchedule("SCHD001"))
            .thenReturn(testSchedule);
        when(scheduleMapper.selectScheduleWithSharedUsers("SCHD001"))
            .thenReturn(testSchedule);
        // when(scheduleMapper.deleteScheduleSharedUsers("SCHD001"))
        //     .thenReturn(1);
        when(scheduleMapper.deleteSchedule("SCHD001"))
            .thenReturn(1);
        when(userService.svcSelectCompnDept("USER001"))
            .thenReturn(testUser);
        when(scheduleMapper.insertSchedule(any(ScheduleDTO.class)))
            .thenReturn(1);

        // When
        // try (MockedStatic<SecurityUtil> mockedSecurityUtil = mockStatic(SecurityUtil.class)) {
        //     mockedSecurityUtil.when(SecurityUtil::getAuthUserId).thenReturn("USER001");

            int result = scheduleService.svcUpdateSchedule(updateSchedule);

            // Then
            assertAll(
                () -> assertEquals(1, result),
                () -> verify(scheduleMapper).selectSchedule("SCHD001"),
                () -> verify(scheduleMapper).selectScheduleWithSharedUsers("SCHD001"),
                // () -> verify(scheduleMapper).deleteScheduleSharedUsers("SCHD001"),
                () -> verify(scheduleMapper).deleteSchedule("SCHD001"),
                () -> verify(userService).svcSelectCompnDept("USER001"),
                () -> verify(scheduleMapper).insertSchedule(any(ScheduleDTO.class))
            );
        // }

    }

 

하면서 로직 검증이 가능했다.
 

deleteScheduleSharedUsers이거 바로 실행되는 줄 알았는데 아래 오류떠서 보니 selectScheduleWithSharedUsers결과 있을때만 실행.

*Wanted but not invoked: 테스트에서 verify한 메서드들이 호출되지 않음.

org.mockito.exceptions.verification.WantedButNotInvoked: Wanted but not invoked: scheduleMapper.deleteScheduleSharedUsers( "SCHD001" );

 

이처럼 Mockito의 verify를 통해 서비스 메서드 내 호출 순서와 조건을 확인가능 했고, 테스트 코드를 단순 검증용뿐 아니라 메서드 실행 흐름 확인용으로도 활용할 수 있을 것 같다.

 

🔹  커버리지와 private 메서드 테스트
조건별 테스트를 작성했을 때 서비스 커버리지는 18%까지 올라갔고, ScheduleService 내 핵심 로직은 50% 이상 커버할 수 있었다. 또한 private 메서드도 public 메서드를 통해 간접적으로 테스트가 가능했다.

 

🔹  나머지 50%에는 사용자 메일/알림(연동서비스) 등이 포함되어서 여기까지만 활용해봄.