[TIL] 단위테스트

👏🏻 단위 테스트

 📍 테스트

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

  - 테스트를 제대로 잘 거쳐서 테스트 대상이 검증 과정에 잘 통과하게 만들어 최대한 더 나은 결과를 얻을 수 있음

---

 📍 테스트 분류

   : 기능 테스트 > 통합 테스트 > 슬라이스 테스트 > 단위 테스트

   ▪️ 기능 테스트

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

   - 일반적으로 QA 부서, QA 업체에서 기능 테스트 수행 : 개발자 이외 제 3자 !

   - API 툴이나 데이터베이스까지 연관되어 있어 HTTP 통신, 데이터베이스 연결 등 단위테스트로 볼 수는 없음

   ▪️ 통합 테스트

   - 애플리케이션을 만든 개발자 또는 개발팀의 테스트의 주체가 되는 것이 일반적

   - 클라이언트 측 툴 없이 개발자가 짜 놓은 테스트 코드를 실행시켜 이루어 짐

   - 애플리케이션의 여러 계층 및 DB와 연결되어 있어 단위 테스트라고 보기 어려움

   ▪️ 슬라이스 테스트

   - 애플리케이션을 특정 계층으로 쪼개어서 하는 테스트

   - API 계층, 서비스 계층, 데이터 엑세스 계층이 각각 슬라이스 테스트의 대상이 될 수 있음

   - Mock 객체를 사용해서 계층별로 끊어서 테스트

   - 해당하는 계층에서 HTTP 요청이 필요하고 외부 서비스가 연동 되기도 하며

      데이터 엑세스 계층은 DB와 연동되어 단위 테스트로 보기 조금 힘듦

   ▪️ 단위 테스트

   - 대부분 메서드 단위로 작성

   - 최대한 독립적일수록, 최대한 작은 단위일 수록 좋음

   - 데이터베이스와 연동된다고 해서 무조건적으로 단위테스트로 부르기 어렵다기 보다는,

      데이터베이스 상태가 테스팅 이전, 이후에 동일하게 유지도리 수 있다면 부를 수는 있음

---

 📍 단위 테스트를 해야하는 이유

   - Intelli-J를 실행하고 Postman으로 HTTP 요청을 보내서 JSON 응답 결과 확인하며 테스트 하는 방법

     → 중요하지만 비생산적

   - 구현한 코드가 의도한 대로 동작 하는지 결과를 빠르게 확인할 수 있음

   - 작은 단위의 테스트라서 미리미리 버그를 찾을 수 있음

   - 테스트 케이스가 잘 짜여져 있어야 버그가 발생하더라도 문제가 발생한 원인을 단계적으로 찾기 용이함

  💡 테스트 케이스 : Test Case

   - 테스트를 위한 입력데이터, 실행 조건, 기대 결과를 표현하기 위한 명세

     → 즉 메서드 등 하나의 단위를 테스트하기 위해 작성하는 테스트 코드

---

 📍 단위 테스트를 위한 F I R S T 원칙

   ① Fast : 빠르게

   - 작성한 테스트 케이스는 빨라야 함

   ② Independent : 독립적으로 

   - 각각의 테스트 케이스는 독립적이어야 함

   - 어떤 테스트 케이스를 먼저 실행시켜도 실행되는 순서와 상관없이 정상적인 실행이 보장되어야 함

   - 하나의 테스트 클래스에서 여러 개의 테스트 케이스를 한 번에 실행할 수 있음

     → 두 개의 테스트 케이스를 한꺼번에 실행하고 순서를 바꿔서 사용하더라도 

         각각의 테스트 케이스는 독립적으로 실행되어 테스트 결과가 바뀌지 않음

   ③ Repeatable : 반복 가능하도록

   - 어떤 환경에서도 반복해서 실행이 가능해야 됨

   - IDE 버튼을 누르든, 빌드 태스크를 직접 입력하든, 로컬 환경이나 서버 환경에서 실행하든지 같은 결과여야 함

   ④ Self-Validating : 셀프 검증이 되도록

   - 성공 또는 실패라는 자체 검증 결과를 보여주어야 함

   - 테스트 케이스 스스로 결과가 옳은지 그른지 판단할 수 있어야 함

   ⑤ Timely : 시기 적절하게 

   - 테스트 하려는 기능 구현을 하기 직전에 작성해야 함

   - 구현하고자 하는 기능을 단계적으로 조금씩 업그레이드 하면서 테스트 케이스 역시 단계적으로 업그레이드

---

📍 JUnit 없이 비즈니스 로직에 단위 테스트 적용  

  - JUnit은 테스트를 하기 위한 표준 테스트 프레임워크

  - 테스트 프레임워크 없이 단위 테스트를 제일 쉽고 빠르게 적용할 수 있는 부분 : 헬퍼 클래스 or 유틸리티 클래스

 💡 유틸리티 클래스 : Utility Class

   - 유틸리티 클래스의 메서드들은 일반적으로 클래스의 객체로 인스턴스화 될 필요가 없어 정적 메서드로 구성

 💡 Given - When - Then 표현 스타일

   - BDD(Behavior Driven Development)라는 테스트 방식에서 사용

   - 단위 테스트에 익숙하지 않거나 테스트 케이스의 가독성을 높이기 위해 사용

     ▪️ Given

     - 테스트를 위한 준비 과정 명시

     - 테스트에 필요한 전제 조건들 포함

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

     - ex) 현재 값, 얻은 값

     ▪️ When

     - 테스트 할 동작 지정

     - ex) 실제 값, 기대하는 값

     ▪️ Then

     - 테스트의 결과를 검증하는 영역

     - ex) 예상하는 값과 동작 수행 결과 값을 비교해서 기대한 대로 동작이 수행하는지 검증하는 코드 포함

💡 Assertion : 어써션 = 단언문, 단정문

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

   - 예상하는 결과 값이 참이기를 바라는 것

---

📍 JUnit 으로 비즈니스 로직에 단위 테스트 적용  

 💡 JUnit :

   - Java의 표준 테스트 프레임워크

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

 ▪️ JUnit을 사용한 테스트 케이스 기본 구조

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

 → 애플리케이션에서 테스트 하고자 하는 대상이 있으면

     ① void 타입 메서드 만들기     ② @Test 애너테이션 추가     ③ 테스트 대상 메서드에 대한 테스트 로직 작성

---

 ▪️ Assertion 메서드 이용

 - 예상하는 결과 값이 참이길 바라는 논리적인 표현 / 검증

  🔹 assertEquals( )

public class JUnitTest {
    @DisplayName("Hello JUnit Test")
    @Test
    public void assertionTest() {
    	String expected = "Hello, JUnit";
        String actual = "Hello, JUnit";
        
        assertEquals(expected, actual);
    }
}

   - assertEquals( )를 사용하여 기대하는 값과실제 결과 값이 같은지 검증할 수 있음

   - @DisplayName( ~ )은 테스트 케이스를 실행시켰을 때 실행 결과 창에 표시되는 이름을 지정하는 부분

---

  🔹 assertNotNull

public class NotNullTest {
    @DisplayName("Assertion Null Test")
    @Test
    public void assertNotNullTest() {
    	String houseName = getHouse("ABC");
        
        assertNotNull(houseName, "Shoud be not null");
    }
    private String getHouse(String unit){
    	return House.map.get(unit);
    }
}

 

   - assertNotNull( )를 사용하여 테스트 대상 객체가 null이 아닌지 테스트 할 수 있음

   - assertNotNull( 테스트 대상 객체, 테스트실패 시 표시할 메시지 )

---

  🔹 assertThrows( )

public class AssertionExceptionTest {
    @DisplayName("throws NullpointerException when map.get()")
    @Test
    public void assertionTrowExceptionTest(){
    	assertThrows(NullpointerException.class, () -> getHouse("AC"));
    }
    
    private String getHouse(String unit){
    	return House.map.get(unit).toUpperCase();
    }
 }

   - assertThrows( )는 호출한 메서드의 동작 과정 중에 예외가 발생하는지 테스트 할 수 있음

   - assertThrows( 발생이 기대되는 예외 클래스, 테스드 대상 메서드 )

   - 테스트 케이스를 실행하면

      →getHouse( )가 호출 →  파라미터로 "AC"를 전달 → 해당하는 키가 있는지 map에서 찾음 → "AC" 키가 map에 존재 X

         → map에서 null 값 반환  → map에서 반환된 값이 null 인 상태에서 toUpperCase()를 호출해서 대문자로 변환 시도

           → NullPointerException 발생 → NullpointerException이 발생할 것으로 기대하여 테스트 실행 결과는 성공 !

---

 ▪️ 테스트 케이스 실행 전, 전처리

  🔸 @BeforeEach

public class BeforeEachTest{
    @BeforeEach
    public void init( ) {
    	System.out.println("Before Each Test Case");
    }
    
    @DisplayName("BeforeEach Test 1")
    @Test
    public void beforeEachTest1() {
    }
    
    @DisplayName("BeforeEach Test 2")
    @Test
    public void beforeEachTest2() {
    }
}

//결과
Before Each Test Case
Before Each Test Case

- init( )이 두 번 실행되어 콘솔에 두 번 출력됨

- @BeforeEach를 추가한 메서드는 테스트 케이스가 각각 실행될 때 마다 테스트 케이스 실행 직전에 먼저 실행되어 초기화 진행

- @Test가 2개니깐 2번 출력된 꼴 !  즉, init( )  →  Test 1  →   init( )  →  Test 2 !!

---

  🔸 @BeforeAll

- @BeforeAll은 클래스 레벨에서 테스트 케이스를 한꺼번에 실행 시키면 딱 한번만 초기화 작업을 하는 애너테이션

   즉, init( )  →  Test 1  →  Test 2 !!

- @BeforeAll을 추가한 메서드는 정적 메서드여야 함

---

 ▪️ 테스트 케이스 실행 후, 후처리

  🔸 @AfterEach, @AfterAll

   - @BeforeEach, @BeforeAll과 동작 방식은 같고 호출 되는 시점만 반대

---

 ▪️ Assumption을 이용한 조건부 테스트

  - Assumption은 ' -라고 가정하고 '라는 표현을 쓸 때의 가정에 해당함

  🔹assumTrue( )

public class AssumptionTest {
    @DisplayName("Assumption Test")
    @Test
    public void assumptionTest( ){
    	assumeTrue(System.getProperty("os.name").startsWith("Windows"));
        System.out.println("execute?");
        assertTrue(processOnlyWindowsTask());
    }
    
    private boolean processOnlyWindowsTask( ) {
    	return true;
    }
 }

  - assumeTrue는 파라미터로 입력된 값이 true 이면 나머지 아래 로직 실행

  - System.getProperty("os.name").startsWith("Windows")는

       테스트케이스를 실행하는 PC 운영체제가 Windows라면 이라는 의미

---

👍🏻 Hamcrest

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

---

 ▪️ Hamcrest를 사용하는 이유

  - Assertion을 위한 매쳐가 자연스러운 문장으로 이어져 가독성 향상

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

  - 다양한 매쳐 제공

---

 ▪️ JUnit Assertion을 사용한 단위테스트에 Hamcrest - Assertion 적용

public class HamcrestTest{
    @DisplayName("Hello Junit Test Using Hamcrest")
    @Test
    public void assertionTest()
    	String expected = "Hello";
        String actual = "Hello";
        
        assertThat(actual, is(equalTo(expected));
   }
}

  ▸ JUnit Assertion 이용 : assertEquals(expected, actual);

   - 파라미터로 입력된 값의 변수 이름을 통해 대략적으로 어떤 검증을 하려는지 알 수 있으나 구체적 의미 유추 필요

  ▸ Hamcrest의 Matcher 이용 : assertThat(actual, is(equalTo(expected));

   - 코드로 assert that acual is equal to expected로 읽을 수 있음 

                 → 결과 값이 기대 값과 같다는 것을 검증한다는 의미

   - assertThat( 테스트 대상의 실제 결과, 기대하는 값 )