🌈 [Section3] 10. [ Spring MVC ] 테스팅 1

📕 오늘 배운 내용!

• 테스트 (Test)
• JUnit
• Hamcrest
• 단위 테스트 / 계층별 슬라이스 테스트 실습

---

✏️ 테스트 (Test)

• 어떤 대상에 대한 일정 기준을 정해놓고, 그 대상이 정해진 기준에 부합하는지 부합하지 못하는지를 검증하는 과정

• JUnit 테스트 프레임워크로 테스팅

✔ 테스트의 종류

✔️ 단위 테스트

• 아주 작은 단위의 기능을 테스트 하는 방법

• 대부분 메서드 단위의 코드로 작성

• 단위 테스트를 제일 쉽고 빠르게 적용할 수 있는 부분
  ➜ 헬퍼(helper) 클래스 or 유틸리티(utility) 클래스

  💡 But, 유틸리티 클래스들의 메서드들은 클래스의 객체로 인스턴스화 될 필요가 없어 모두 정적(static)메서드로 구성
  ➜ 객체 지향적인 시각으로 사용 지양 But, 많이 사용함

• 단위테스트 장점

  • 구현 코드가 의도대로 동작하는지 빠르게 결과 확인 가능

  • 번거로운 테스트 일들 단순화

  • 작은 단위로 미리 버그를 찾아낼 수 있어 상대적으로 더 적은 시간 내에 문제 찾기 가능

💬 그럼 DB를 사용한다면 단위 테스트라고 보기 힘들까?
➜ 단위 테스트는 최대한 독립적이고 작은 단위인 것이 좋지만,
데이터베이스의 상태가 테스트 이전과 이후가 동일하게 유지될 수 있다면, 데이터베이스가 연동된다고 해도 단위 테스트에 포함될 수는 있음

✔️ 기능 테스트

• 애플리케이션을 사용하는 사용자 입장에서 애플리케이션이 제공하는 기능이 올바르게 동작하는지를 테스트

• 개발한 애플리케이션과 연관된 대상이 많아 단위 테스트라 부르기 힘듦

• 테스트를 하는 주체가 주로 개발자 이외의 제 3자
  Ex. 테스트 전문 부서(QA 부서), 외부 QA 업체 등

✔️ 통합 테스트

• 클라이언트 측 툴 없이, 개발자가 짜 놓은 코드를 실행시켜 하는 테스트

• 여러 계층과 연관되어 있으므로 단위 테스트라 부르기 힘듦

✔️ 슬라이스 테스트

• 애플리케이션을 특정 계층으로 쪼개서 하는 테스트
  Ex. API 계층 / 서비스 계층 / 데이터 엑세스 계층

• 단위 테스트라고 부르기엔 단위가 큰 테스트

• 애플리케이션의 일부만 테스트하기 때문에 부분 통합 테스트라고 부르기도 함

✔️ 스모크 테스트 (Smoke Test)

• 통합 테스트는 아니지만 QA 부서에서 본격적으로 전체적인 기능 테스트를 진행하기 전, 애플리케이션의 특정 수정 사항으로 인해 영향을 받을 수 있는 범위에 한해서 제한된 테스트
  [참고] https://en.wikipedia.org/wiki/Smoke_testing_(software)

✔️ 테스트 케이스 (Test Case)
➜ 하나의 단위를 테스트하기 위해 작성하는 테스트 코드

---

✏️ 단위 테스트 F.I.R.S.T 원칙

• Fast (빠르게)
  ➜ 테스트 케이스는 동작이 빨라야함

• Independent (독립적으로)
  ➜ 각 테스트가 독립적이어야 함
  ( 결과도 각각에 영항을 미치지 않아야 함 )

• Repeatable (반복 가능하도록)
  ➜ 어떤 환경에서도 반복 실행이 가능해야함
  ➜ 외부 서비스 / 외부 리소스가 연동된 경우 동일한 테스트 결과 보장 X

• Self-validating (셀프 검증이 되도록)
  ➜ 테스트 케이스 스스로 결과가 성공 / 실패 인지를 판단할 수 있어야함

• Timely (시기 적절하게)
  ➜ 테스트하려는 기능 구현 직전에 작성해야함 (TDD (테스트 주도 개발))
  ( 구현하고자 하는 기능을 다 작성하고 실행시키지 않고 짧게 작성하고 돌려보고 점점 업그레이드하는 식으로 )

---

✏️ JUnit 없이 단위 테스트

• Given - When - Then 표현 스타일
  ( BDD 테스트 방식에서 사용하는 용어 )

  ✔️ BDD (Behavior Driven Development)

  • 행동 중심 개발
  • 소프트웨어 프로젝트에서 개발자, 품질 보증 전문가 및 고객 담당자 간의 협업을 장려하는 민첩한 소프트웨어 개발 프로세스
    [참고] https://en.wikipedia.org/wiki/Behavior-driven_development

• Given

  • 테스트하고자 하는 대상

  • 테스트를 위한 전제 조건들이 포함

  • 테스트 대상에 전달되는 입력 값(테스트 데이터)도 포함

• When

  • 테스트의 동작 지정

• Then

  • 테스트의 결과를 검증 (Assertion)

  • 예상하는 값(expected)과 테스트 대상 메서드의 동작 수행 결과(actual) 값을 비교해서 기대한대로 동작을 수행하는지 검증(Assertion)하는 코드들

✔️ Assertion (검증)

• 테스트 케이스의 결과가 반드시 참(true)이어야 한다는 것을 논리적으로 표현한 것

---

✏️ JUnit

• Java 언어로 만들어진 애플리케이션을 테스트 하기 위한 오픈 소스 테스트 프레임워크

• Java의 표준 테스트 프레임워크라고 해도 과언이 아님

• TestNG라는 JUnit의 강력한 경쟁자가 있긴하지만, Spring Boot의 디폴트 테스트 프레임워크는 JUnit

• assertXXXX()로 시작하는 다양한 Assertion 메서드를 지원

• JUnit으로 작성한 테스트 케이스는 항상 일정한 순서로 테스트 케이스 실행 X ( 순서 랜덤 )
  ➜ 각각 테스트 케이스에 독립성이 보장되어야 함

  Ex. 한 테스트 케이스에서 테스트를 위해 정보를 delete 했다면, 다른 테스트에는 이 delete한 행위가 영향을 미치지 않도록 다시 처음으로 초기화 되어야 함
  ➜ @Transactional 애너테이션 붙임

💡 Spring Boot Initializer 사용하여 프로젝트 생성한다면 기본적으로 testImplementation >'org.springframework.boot:spring-boot-starter-test' 스타터가 포함되며, 자동으로 JUnit도 포함

✔ JUnit을 사용한 테스트 케이스의 기본 구조

public class JunitDefaultStructure {
	 @Test
    public void test1() {
        // 테스트 하고자 하는 대상에 대한 테스트 로직 작성
    }
    
     @Test
    public void test2() {
        // 테스트 하고자 하는 대상에 대한 테스트 로직 작성
    }
    .
    .
    .
}

➜ 위와 같이 void 타입의 메서드를 만들고 그에 @Test 애너테이션을 추가해줘야 함

• @DisplayName("표시할 이름") 애너테이션을 붙여주면 아래와 같이
  해당 테스트 케이스의 실행 결과에 내가 적은 이름으로 표시됨
  

❗ 테스트에서 예외가 발생했다고 무조건 failed가 아닌,
우리가 기대한 값(통과 or 예외)이 결과 값과 일치하는지에 따라 passed / failed를 결정하는 것임을 알기 !

✔ Assertion 메서드

➜ 테스트가 원하는 결과를 제대로 리턴하는지 에러는 발생하지 않는지 확인할 때 사용하는 메서드

❗ 개발자가 테스트하고 싶은 인자값을 넣었을 때 예상한 결과가 나오는지 테스트 해볼 경우 사용 ( 사실임을 주장 )

• assertEquals(기대하는 문자열, 실제 결과 값)
  ➜ 기대하는 값과 실제 결과 값이 일치하는지 검증

• assertTrue(예상할 대상)
  ➜ 대상이 true인지 검증

• assertFalse(예상할 대상)
  ➜ 대상이 false인지 검증

• assertNotNull(테스트 대상 객체, 테스트 실패시 표시할 메세지)
  ➜ Null이 아닌지 여부 테스트
  ( Null이 아니면 passed / Null이면 failed )

• assertNull(테스트 대상 객체, 테스트 실패시 표시할 메세지)
  ➜ Null인지 여부 테스트
  ( Null이면 passed / Null이 아니면 failed )

• assertThrows(발생이될 것으로 예상되는 예외 클래스, 람다식으로 테스트 대상 메서드 호출)
  ➜ 예상한 예외(Exception)가 발생했는지 테스트

Ex.

@Test
public void assertionThrowExceptionTest() {
		assertThrows(NullPointerException.class, () -> getColor("RED"));
}
⠀
private String getColor(String unit) {
        return Color.map.get(unit).toUpperCase();
}

위의 예시에서 RED라는 색이 없으면 assertThrows()는 null이라는 결과를 반환할 것.
그런데 밑에서 null인 값에 toUpperCase() 메서드로 대문자로 변환하려고 하기 때문에
결국은 NullPointerException이 발생하게 됨
➜ 우리가 예상한 예외 값이 NullPointerException이 맞기 때문에 테스트 passed
⠀
❗ assertThrows() 메서드 내의 ExpectedType 을 상위 타입입인 RuntimeException.class 이나 Exception.class 으로 입력해도 결과는 passed !
( NullPointerException extends RuntimeException / RuntimeException extends Exception )
➜ 예외 클래스의 상속 관계를 이해한 상태에서 테스트 실행 결과 예상해야함

[참고] https://beomseok95.tistory.com/205
[Assertions 참고] https://junit.org/junit5/docs/current/user-guide/#writing-tests-assertions

✔ Assumption 메서드

➜ 메소드별 조건을 만족할 경우 진행시키고 아닌 경우 스킵하는 메소드

❗ 개발자가 인자값을 정확히 모를 때 if 와 같은 용도로 사용 ( 가정 / 추정 )

• assumeTrue()
  ➜ 파라미터로 입력된 값이 true이면 나머지 아래 로직들을 실행

• assumeFalse()
  ➜ 파라미터로 입력된 값이 false이면 나머지 아래 로직들을 실행

[Assunptions 참고] https://junit.org/junit5/docs/current/user-guide/#writing-tests-assumptions
[Assertion / Assumption 차이 참고] https://effortguy.tistory.com/123

✔ 테스트 케이스 실행 전, 전처리

• @BeforeEach

  • 클레스 레벨에 사용

  • 각 테스트 케이스가 실행될 때 마다 이 애너테이션을 붙인 메서드의 내용들이 실행된 후, 해당 테스트 케이스 실행
    ⠀

    Ex.

    public class BeforeEachTest {
        private Map<String, String> map;
    ⠀
        @BeforeEach
        public void init() {
            map = new HashMap<>();
            map.put("RED", "Red");
            map.put("BLA", "Black");
        }
    ⠀
        @DisplayName("Test case 1")
        @Test
        public void beforeEachTest1() {
            map.put("WHI", "White");
            assertDoesNotThrow(() -> getCryptoCurrency("WHI"));
            // 결과 --> passed ( Assertion 하기 전에 map 에 “XRP”를 추가했기 때문 )
        }
    ⠀
        // Test case 2 실행되기 전, init() 메서드가 호출되면서 map 객체 다시 초기화
        // --> 앞 테스트 케이스에서 WHI 추가 했더라도 다시 초기화되어 이전 상태로 되돌아감
        @DisplayName("Test case 2")
        @Test
        public void beforeEachTest2() {
            System.out.println(map);
            assertDoesNotThrow(() -> getColor("WHI"));
            // 결과 --> failed
            // 예외 발생하지 않을 것이라고 기대했는데, Assertion 하기 전에
            // map 에 “WHI”를 추가하지 않아서 안에 값이 없어서 예외 발생했기 때문
        }
    ⠀
        private String getColor(String unit) {
            return map.get(unit).toUpperCase();
        }
    }

• @BeforeAll()
  • 클레스 레벨에 사용
  • 테스트 케이스를 한꺼번에 실행 시키면, 테스트 케이스들이 실행되기 전에 딱 한번만 이 애너테이션이 붙은 메서드의 내용들이 실행된 후 테스트 케이스들이 실행
  • 이 애너테이션이 포함된 메서드는 꼭 정적(static)메서드
    ⠀⠀

    Ex.

    public class BeforeAllTest {
        private static Map<String, String> map;
    ⠀
        @BeforeAll // 이 애너테이션을 추가한 메서드는 정적(static) 메서드여야 함 !!
        public static void initAll() {
            map = new HashMap<>();
            map.put("RED", "Red");
            map.put("BLA", "Black");
    ⠀⠀
            System.out.println("initialize Color map");
            // 결과 --> 두 케이스 통틀어서 초기화가 한번만 되기 때문에
            // "initialize Color map" 한번 출력
        }
    ⠀
        @DisplayName("Test case 1")
        @Test
        public void beforeEachTest1() {
        	map.put("WHI", "White");
            assertDoesNotThrow(() -> getColor("WHI"));
        }
    ⠀
        @DisplayName("Test case 2")
        @Test
        public void beforeEachTest2() {
            assertDoesNotThrow(() -> getColor("WHI"));
            // 결과 --> passed 초기화가 테스트1 진행 전에 한번 되기 때문에,
            // test1에서 저장한 값이 사라지지 않고 남게 되어 조회 가능
        }
    ⠀
        private String getColor(String unit) {
            return map.get(unit).toUpperCase();
        }
    }

✔ 테스트 케이스 실행 후, 후처리

• @AfterEach

• @AfterAll

( 위 전처리 애너테이션이랑 동작방식은 같고, 호출되는 시점만 반대 )

---

✏️ Hamcrest

• JUnit 기반의 단위 테스트에서 사용할 수 있는 Assertion Framework

• Assertion을 위한 매쳐(Matcher)의 제공으로 사람이 읽기 편한 자연스러운 Assertion 문장 구성
  ➜ 가독성 향상

• 테스트 실패 메시지를 이해하기 쉬움

➜ 위의 장점들때문에 JUnit에 지원하는 Assertion 메서드 보다 더 많이 사용

💡 But, 예외에 대한 테스트는 Hamcrest 만으로 Assertion 구성이 힘듦
➜ JUnit 의 assetThrows() 메서드 이용
⠀

• Hamcrest 만으로 던져진(thrown) 예외를 테스트 하고 싶다면,
  Custom Matcher를 직접 구현해서 사용

[참고] http://hamcrest.org/JavaHamcrest/tutorial

✔ Hamcrest에서 지원하는 매쳐(Matcher)

✔️ assertThat( 테스트 대상의 실제 결과값, 예상하는 값 )

• assertEquals()를 사용하는 것보다 하나의 영어 문장으로 자연스럽게 읽혀 더 구체적인 의미 유추 가능
• 실행 결과 또한 더 자연스럽게 읽힘

• is()
  ➜ 가독성을 높이기 위한 decorator

• equalTo()
  ➜ 객체가 동일한지 판단

  Ex. ( 아래 세 예시는 동일함 )

  • assertThat(theBiscuit, equalTo(myBiscuit));
  • assertThat(theBiscuit, is(equalTo(myBiscuit)));
  • assertThat(theBiscuit, is(myBiscuit));

• hasToString()
  ➜ 메서드 값과 일치 여부 판단

• notNullValue() /nullValue()
  ➜ Null인지 아닌지 판별

[참고] http://hamcrest.org/JavaHamcrest/javadoc/2.2/
[Matcher 종류 참고] https://velog.io/@hanblueblue/spring-boot-%EC%9C%A0%EB%8B%9B-%ED%85%8C%EC%8A%A4%ED%8A%B8-4.Hamcrest

---

✏️ 슬라이스 테스트

• 각 계층에 구현해 놓은 기능들이 잘 동작하는지 특정 계층만 잘라서(Slice) 테스트하는 것

✔ API 계층 테스트

• API 계층의 테스트 대상 - Controller

✔️ Controller 슬라이스 테스트의 목적 !!

• 구체적인 로직을 테스트하기 위함이 아닌,
  HTTP request부터 response 구간까지 이상없이 동작하거 DTO 유효성 검증이 잘 일어나는지 확인하기 위함
  ( 요청, 응답이 잘 들어오고 DTO 유효성 검증이 잘 일어나냐 )

✔️ Controller 테스트를 위한 테스트 클래스 구조

@SpringBootTest
@AutoConfigureMockMvc
public class ControllerTestDefaultStructure {
⠀
    @Autowired
    private MockMvc mockMvc;
   ⠀  
    @Test
    public void postMemberTest() {
    // 테스트하고자 하는 Controller 핸들러 메서드의 테스트 케이스 작성
       ⠀  
        // given
        // 테스트용 request body 생성
     ⠀   
        // when
        // MockMvc 객체로 테스트 대상 Controller 호출
        // ( MockMvc 객체를 통해 요청 URI / HTTP 메서드등 지정하고, given 에서 만든
        // 테스트용 request body 를 추가한 뒤, request 수행 )
       ⠀ 
        // then
        // Controller 핸들러 메서드에서 응답으로 수신한 HTTP Status / response body 검증 
    }
}

• @SpringBootTest

  • Spring Boot 기반의 애플리케이션을 테스트 하기 위한 Application Context 생성
    ( Application Context 에는 애플리케이션에 필요한 Bean 객체들이 등록되어 있음 )

  • 통합 테스트에 적합

• @AutoConfigureMockMvc

  • Controller 테스트를 위한 애플리케이션의 자동 구성 작업을 해줌
    ( 테스트에 필요한 애플리케이션의 구성이 자동으로 진행 )

• MockMvc

  • Tomcat 같은 서브릿 컨테이너를 실행하지 않고 Spring 기반 애플리케이션의 Controller 를 테스트 할 수 있는 완벽한 환경을 지원해주는 일종의 Spring MVC 테스트 프레임워크

  • @AutoConfigureMockMvc 애너테이션을 꼭 달아야 사용 가능

    [참고] https://docs.spring.io/spring-framework/docs/current/reference/html/testing.html#spring-mvc-test-framework

✔️ @WebMvcTest를 이용한 Controller 테스트

• Controller를 테스트 하기 위한 전통적인 방법
• 웹 계층 전용 슬라이스 테스트에 적합
• 테스트하는 데 필요한 빈들만 등록해서 사용
  ⠀
  But, Controller에서 의존하는 컴포넌트들을 모두 일일이 설정해줘야하고,
  때에 따라서 데이터액세스 계층에서 의존하는 설정/의존 객체들도 모두 설정해 주어야 할 수도 있는 불편함 있음
  ⠀
  ➜ @SpringBootTest, @AutoConfigureMockMvc를 이용해서 Controller 테스트를 위한 구성의 복잡함을 해결
  ⠀
  ❗ But, 각각의 장단점이 존재하므로 상황에 맞게 적절하게 사용 !

✔️ 각 단계에서 사용하는 메서드 정리

• 요청수행
  ➜ perform()

• Http Method, request URL, path variable을 위한 API 메서드
  ➜ MockMvcRequestBuilders.post(...), MockMvcRequestBuilders.patch(...), MockMvcRequestBuilders.get(...), MockMvcRequestBuilders.delete(...)
  ⠀
  ❗ MockMvcRequestBuilders - GET, POST, PUT, DELETE 요청 방식과 매핑되는 get(), post(), put(), delete() 메소드를 제공

[참고] https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/test/web/servlet/request/MockMvcRequestBuilders.html

• request body를 위한 API 메서드
  ➜ content(...)

• query parameter
  ➜ params(...)

• response body 검증
  ➜ andExpect(jsonPath("$.data.~~").value(...))

[참고]
https://www.baeldung.com/guide-to-jayway-jsonpath
https://scshim.tistory.com/321

✔ 데이터 액세스 계층 테스트

( 실습에서 현재 데이터 엑세스 계층에서 사용하고 있는 기술 - Spring Data JPA )

❗ DB의 상태를 테스트 케이스 실행 이전으로 되돌려서 깨끗하게 만들어야함
➜ 각각의 테스트 케이스에 독립성이 보장되어야 함

Ex. DB에 임의의 정보를 저장하고 그것이 잘 조회되는지 테스트를 했었으면,
그 저장한 값은 다시 삭제해주어 DB를 원래대로 보존시켜놓아야 함

✔️ Repository 테스트를 위한 테스트 클래스 구조

@DataJpaTest
public class RepositoryTestDefaultStructure {
⠀
    @Autowired
    private MemberRepository memberRepository;
   ⠀  
    @Test
    public void saveMemberTest() {
    // 테스트하고자 하는 Controller 핸들러 메서드의 테스트 케이스 작성
       ⠀  
        // given
        // 테스트용 데이터 준비 ( 객체에 데이터 저장 )
     ⠀   
        // when
        // Repository에 객체 저장
        // 정보들 중 하나만 뽑아 검증하고 싶다면 Repository의 findByXXX() 메서드 사용
       ⠀ 
        // then
        // 정보가 잘 저장되었는지 검증 (Assertion)
    }
}

• @DataJpaTest

  • 데이터 액세스 계층을 테스트 하기 위한 가장 핵심적인 방법

  • 해당 Repository의 기능을 정상적으로 사용하기 위한 Configuration을 Spring이 자동으로 해줌
    ( 데이터 액세스 계층에 필요한 자동구성 활성화 )

  • @Transactional 애너테이션을 포함하고 있음

• @Transactional

  • 하나의 테스트 케이스 실행이 종료되는 시점에 데이터베이스에 저장된 데이터는 rollback 처리됨
    ( 여러 테스트 실행시켜도 하나의 테스트가 종료될 때 마다 DB 가 초기 상태 유지 )

---

😜 실습

• projects - be-template-testing
• git - be-homework-testing-junit
• git - be-homework-testing-slice

........................................................................................................................................................................................................
💡 결과를 콘솔창에서 확인할 때 response body 응답 데이터에 포함된 한글이 깨질 경우,
application.yml 파일에 아래의 설정을 추가

server:
  servlet:
    encoding:
      force-response: true

........................................................................................................................................................................................................
But, Controller 테스트에서 오늘 작성한 실습 내용은 Controller만 테스트하는 것이 아니라 애플리케이션의 전체 로직을 모두 실행하게됨

➜ 완전한 슬라이스 테스트라고 보기에는 힘듦

➜ 이 문제는 Mock(가짜) 객체를 사용해 계층 간의 연결을 끊어줌으로써 해결이 가능

---

🌈 느낀점

테스팅하는 부분 학습은 재밌는 것 같다 !
테스팅이 잘 됐을 때 ✔️ 이 표시가 나오는 게 뭔가 뿌듯 ..!
실습은 다 괜찮았는데 getMembers 테스팅 부분이 어려웠다. ( 이건 다시 한번 더 보기 ! )