Jin's Dev Story

[SpringBoot] JUnit 테스트 본문

Web & Android/SpringBoot

[SpringBoot] JUnit 테스트

woojin._. 2023. 7. 27. 15:13

JUnit

  • 자바 프로그래밍 언어용 단위 테스트 프레임워크
  • 어노테이션 기반으로 테스트를 지원
  • 단정문(Assert)를 통해 테스트 케이스의 기대값에 대해 수행 결과를 확인할 수 있음
  • JUnit5 → 크게 Jupiter, Platform, Vintage 모듈로 구성되어있음
Annotation  Description
@Test 테스트용 메소드를 표현하는 어노테이션
@BeforEach 각 테스트 메소드가 시작되기 전에, 실행되어야 하는 메소들 표현
@AfterEach 각 테스트 메소드가 시작된 후 실행되어야 하는 메소드르 표현
@BeforeAll 테스트 시작 전에 실행되어야 하는 메소드를 표현(Static 처리 필요)
@AfterAll 테스트 종료 후에 실행되어야 하는 메소드를 표현(Static 처리 필요)

Junit Main Annotation

1. @SpringBootTest

  • 통합 테스트 용도로 사용됨
  • @SpringBootApplication을 찾아가 하위의 모든 Bean을 스캔하여 로드함
  • 그 후 Test용 Application Context를 만들어 Bean을 추가하고, MockBean을 찾아 교체

2. @ExtendWith

  • JUnit4에서 @RunWith로 사용되던 어노테이션이 ExtendWith로 변경됨
  • @ExtendWith는 메인으로 실행될 Class를 지정할 수 있음
  • @SpringBootTest는 기본적으로 @ExtendWith가 추가되어 있음

3. @WebMvcTest(Class명.class)

  • ( )안에 작성된 클래스만 실제로 로드하여 테스트를 진행
  • 매게변수를 지정해주지 않으면 @Controller, @RestController, @RestControllerAdvice 등 컨트롤러와 연관된 Bean이 모두 로드됨
  • 스프링의 모든 Bean을 로드하는 @SpringBootTest대신 컨트롤러 관련 코드만 테스트할 경우 사용

4. @Autowired about Mockbean

  • Controller의 API를 테스트하는 용도인 MockMvc 객체를 주입 받음
  • Perform()메소드를 활용하여 컨트롤러의 동작을 확인할 수있음
  • andExpect(), andDo(), andReturn() 등의 메소드를 같이 활용함

5. @MockBean

  • 테스트할 클래스에서 주입 받고 있는 객체에 대해 가짜 객체를 생성해주는 어노테이션
  • 해당 객체는 실제 행위를 하지 않음
  • given() 메소드를 활용하여 가짜 객체의 동작에 대해 정의하여 사용할 수 있음

6. @AutoConfigureMockMvc

  • spring.test.mockmvc의 설정을 로드하면서 MockMvc의 의존성을 자동으로 주입
  • MockMvc 클래스는 REST API 테스트를 할 수 있는 클래스

7. @Import

  • 필요한 Class들을 Configuration으로 만들어 사용할 수 있음
  • Configuration Component 클래스도 의존성 설정할 수 있음
  • Import된 클래스는 주입으로 사용 가능

 

Junit Life Cycle

  1. BeforeAll 이 제일 먼저 실행
  2. beforeEach가 각 메서드가 실행되기 전 실행,
  3. afterEach가 각 메서드 실행 후 호출
  4. @Disabled를 만나면 함수 호출 X
class PostTest {
    @BeforeAll
    static void beforeAll() {
        System.out.println("## BeforeAll Annotation 호출 ##");
        System.out.println();
    }

    @AfterAll
    static void afterAll() {
        System.out.println("## afterAll Annotation 호출 ##");
        System.out.println();
    }

    @BeforeEach
    void beforeEach() {
        System.out.println("## beforeEach Annotation 호출 ##");
        System.out.println();
    }

    @AfterEach
    void afterEach() {
        System.out.println("## afterEach Annotation 호출 ##");
        System.out.println();
    }

    @Test
    void test1() {
        System.out.println("## test1 시작 ##");
        System.out.println();
    }

    @Test
    @DisplayName("Test Case 2!!!")
    void test2() {
        System.out.println("## test2 시작 ##");
        System.out.println();
    }

    @Test
    @Disabled
        // Disabled Annotation : 테스트를 실행하지 않게 설정하는 어노테이션
    void test3() {
        System.out.println("## test3 시작 ##");
        System.out.println();
    }
}

assertEquals(a, b): a와 b의 값이 동일한지 확인
assertSame(a, b): a와 b의 객체가 동일한지 확인
assertNull(a): a가 null인지 확인
assertNotNull(a): a가 null이 아닌지 확인
assertTrue(a): a가 true인지 확인
assertFalse(a): a가 false인지 확인
assertThrows(입셉션 에러 종류 a, 발생하는 로직 b) : b 로직시에 a 입셉션이 발생하는지 확인
assertThat : AssertJ 라이브러리에 포함된 메서드, 어떤 조건이 참인지 확인

 

테스트 코드를 작성하는 이유

1) Test 코드를 작성하지 않고 결과를 검증하는 과정은 비용이 많이 든다.

  • Test 코드 사용 하지 않는 경우
    1. 검증 코드 작성
    2. 애플리케이션 실행
    3. PostMan 혹은 브라우저 Request 요청
    4. log 혹은 print로 결과 검증
    5. 원하지 않는 결과 발생 시 애플리케이션 종료
    6. 다시 코드 작성
    7. 위의 과정 반복
  • Test 코드 사용
    1. Test 코드 작성
    2. Test 코드 실행
    3. 결과 검증
    4. Test 코드 수정

2) 계층 별로 Test를 진행한다면 어느 부분이 잘못된 지 쉽게 파악 가능

  • Controller : 클라이언트 요청을 받고 클라이언트에게 결과를 반환 (Presentation Layer)
  • Service : 비즈니스 로직을 실행하고 결과 반환(Service Layer)
  • Repository : database에 쿼리를 이용해서 CRUD를 하는 계층(Data Access Layer)
  • Domain : Entity 클래스

 

단위 테스트

  • 프로그램을 작은 단위로 쪼개서 각 단위가 정확하게 동작하는지 검사하는 테스트

   ⇒ 하나의 기능 혹은 메서드

장단점

1) 장점

  • 새로운 기능에 대해서 빠르게 작성 가능
  • Test 코드 자체가 하나의 문서
  • 시간과 비용의 절감

2) 단점

  • 독립적인 테스트이므로 다른 객체와 상호작용 처리를 위해서 가짜 객체 정의 필요함
  • 가짜 객체의 답변 작성 필요함
  • 실제 운영 환경과 다른 답변을 내놓을 수 있는 가능성이 있음

 

통합 테스트

  • 모듈을 통합하는 과정에서 모듈 간의 호환성을 확인하는 테스트

    ⇒ unit이 하나였다면 반대로 여러 개의 계층이 테스트에 참여한 것

장단점

1) 장점

  • 실제 객체를 사용하므로 가짜 객체 사용하지 않아 정의하지 않아도 됨
  • 실제 운영 환경과 같은 값을 도출 가능함

2) 단점

  • 테스트 하나의 많은 비용이 들어감
  • 어느 계층에서 발생한 문제인지 파악하지 힘듦