[TDD] 단위 테스트(Unit Test)

1. 단위 테스트 vs 통합 테스트 차이

[ 단위 테스트(Unit Test) ]

단위 테스트(Unit Test)는 하나의 모듈을 기준으로 독립적으로 진행되는 가장 작은 단위의 테스트이다. 여기서 모듈은 애플리케이션에서 작동하는 하나의 기능 또는 메소드로 이해할 수 있다. 예를 들어 웹 애플리케이션에서 로그인 메소드에 대한 독립적인 테스트가 1개의 단위테스트가 될 수 있다.

즉, 단위 테스트는 애플리케이션을 구성하는 하나의 기능이 올바르게 동작하는지를 독립적으로 테스트하는 것으로, "어떤 기능이 실행되면 어떤 결과가 나온다" 정도로 테스트를 진행한다.

[ 통합 테스트(Integration Test) ]

통합 테스트(Integration Test)는 모듈을 통합하는 과정에서 모듈 간의 호환성을 확인하기 위해 수행되는 테스트이다.

일반적으로 애플리케이션은 여러 개의 모듈들로 구성이 되고, 모듈들끼리 메세지를 주고 받으면서(함수 호출) 기능을 수행한다. 그렇기에 통합된 모듈들이 올바르게 연계되어 동작하는지 검증이 필요한데, 이러한 목적으로 진행되는 테스트가 통합 테스트이다. 그렇기에 통합 테스트는 독립적인 기능에 대한 테스트가 아니라 웹 페이지로부터 API를 호출하여 올바르게 동작하는 지를 확인하는 것이다.

---

2. 단위 테스트(Unit Test) 작성의 필요성

[ 단위 테스트(Unit Test) 작성의 필요성 ]

일반적으로 실무에서 테스트 코드를 작성한다고 하면 거의 단위 테스트를 의미한다. 통합 테스트는 실제 여러 컴포넌트들 간의 상호작용을 테스트하기 때문에 모든 컴포넌트들이 구동된 상태에서 테스트를 하게 된다. 그렇기에 통합 테스트를 위해서는 캐시나 데이터베이스 등 다른 컴포넌트들과 실제 연결을 해야 하고, 시스템을 구성하는 컴포넌트들이 많아질수록 테스트를 위한 비용(시간)이 상당히 커진다. 반면에 단위 테스트는 해당 부분만 독립적으로 테스트하기 때문에 어떤 코드를 리팩토링하여도 빠르게 문제 여부를 확인할 수 있다.

• 테스팅에 대한 시간과 비용을 절감할 수 있다.
• 새로운 기능 추가 시에 수시로 빠르게 테스트 할 수 있다.
• 리팩토링 시에 안정성을 확보할 수 있다.
• 코드에 대한 문서가 될 수 있다.

그렇기 때문에 실무에서는 단위 테스트를 선호하며, 요즘 많이 사용되는 TDD(Test-Driven Development, 테스트 주도 개발) 에서 얘기하는 테스트도 단위 테스트를 의미한다. 우리는 우리가 작성한 테스트 코드를 수시로 빠르게 돌리면서 문제를 파악할 수 있다. 

[ 단위 테스트의 문제점과 Stub ]

어떤 객체가 자체적으로 모든 일을 처리한다면 문제가 없겠지만, 일반적인 애플리케이션에서는 1개의 기능을 처리하기 위해 다른 객체들과 메세지를 주고 받아야 한다. 하지만 앞서 설명하였듯 단위 테스트는 해당 모듈에 대한 독립적인 테스트이기 때문에 다른 객체와 메세지를 주고 받는 경우에 문제가 발생한다. 그렇기 때문에 다른 객체 대신에 가짜 객체(Mock Object)를 주입하여 어떤 결과를 반환하라고 정해진 답변을 준비시켜야 하는데, 이를 stub이라고 한다.

예를 들어 데이터베이스에 새로운 데이터를 추가하는 코드를 테스트한다고 하면, 가짜 데이터베이스(Mock Database)를 주입하여 insert 처리 시에 반드시에 1을 반환하도록 해주는 것이 stub이다.

[ 좋은 단위 테스트의 특징 ]

일반적으로 요구 사항은 계속해서 변하고, 그에 맞춰 우리의 코드 역시 변경되어야 한다. 하지만 실제 코드를 변경한다는 것은 잠재적인 버그가 발생할 수 있음을 내포하는데, 좋은 테스트 코드가 있다면 변경된 코드를 검증함으로써 이를 해결할 수 있다. 또한 실제 코드가 변경되면 테스트 코드 역시 변경이 필요할 수 있는데, 이러한 이유로 우리는 테스트 코드 역시 가독성있게 작성할 필요가 있다.

그렇기에 테스트를 작성하는 경우에는 다음을 준수하는 것이 좋다.

1. 1개의 테스트 함수에 대해 assert를 최소화하라
2. 1개의 테스트 함수는 1가지 개념 만을 테스트하라

또한 좋고 깨끗한 테스트 코드는 FIRST라는 5가지 규칙을 따라야 한다.

1. Fast: 테스트는 빠르게 동작하여 자주 돌릴 수 있어야 한다.
2. Independent: 각각의 테스트는 독립적이며 서로 의존해서는 안된다.
3. Repeatable: 어느 환경에서도 반복 가능해야 한다.
4. Self-Validating: 테스트는 성공 또는 실패로 bool 값으로 결과를 내어 자체적으로 검증되어야 한다.
5. Timely: 테스트는 적시에 즉, 테스트하려는 실제 코드를 구현하기 직전에 구현해야 한다.

(위의 내용들은 CleanCode 책에서 참고한 내용들입니다.)

---

3. Java 단위 테스트(Unit Test) 작성 준비

[ 필요한 라이브러리 ]

요즘 Java 단위테스트 작성에는 크게 2가지 라이브러리가 사용된다.

• JUnit5: 자바 단위 테스트를 위한 테스팅 프레임워크
• AssertJ: 자바 테스트를 돕기 위해 다양한 문법을 지원하는 라이브러리

JUnit 만으로도 단위 테스트를 충분히 작성할 수 있다. 하지만 JUnit에서 제공하는 assertEquals()와 같은 메소드는 AssertJ가 주는 메소드에 비해 가독성이 떨어진다. 그렇기 때문에 순수 Java 애플리케이션에서 단위 테스트를 위해 JUnit5와 AssertJ 조합이 많이 사용된다.

[ given/when/then 패턴 ]

요즘 단위테스트는 거의 given-when-then 패턴으로 작성하는 추세이다. given-when-then 패턴이란 1개의 단위 테스트를 3가지 단계로 나누어 처리하는 패턴으로, 각각의 단계는 다음을 의미한다.

• given(준비): 어떠한 데이터가 준비되었을 때
• when(실행): 어떠한 함수를 실행하면
• then(검증): 어떠한 결과가 나와야 한다.

추가적으로 어떤 메소드가 몇번 호출되었는지를 검사하기 위한 verify 단계도 사용하는 경우가 있는데, 그렇게 실용성이 크지 않으므로 메소드의 호출 횟수가 중요한 테스트에서만 선택적으로 사용하면 될 것 같다.

[ 테스트 코드 작성 공통 규칙 ]

@DisplayName("로또 번호 갯수 테스트")
@Test
void lottoNumberSizeTest() {
    // given

    // when

    // then
}

 

@Test는 해당 메소드가 단위 테스트임을 명시하는 어노테이션이다. JUnit은 테스트 패키지 하위의 @Test 어노테이션이 붙은 메소드를 단위 테스트로 인식하여 실행시킨다. 이 상태로 실행하면 테스트 이름이 함수 이름이 default로 지정되는데, 우리는 @DisplayName 어노테이션을 사용하여 읽기 좋은 다른 이름을 부여할 수 있다

또한 테스트 코드는 앞서 설명한 given-when-then 구조로 흔히 작성되는데, 단위 테스트 내에 주석으로 이 단계를 명시해주면 읽기 좋은 테스트 코드를 작성할 수 있다. (IntelliJ를 사용중이라면 live template를 직접 설정해 빠르게 작성할 수 있다.)

 실제 단위 테스트 : https://mangkyu.tistory.com/144 참고

---

4. Mockito 소개 및 사용법

[ Mockito란? ]

Mockito는 개발자가 동작을 직접 제어할 수 있는 가짜(Mock) 객체를 지원하는 테스트 프레임워크이다. 일반적으로 Spring으로 웹 애플리케이션을 개발하면, 여러 객체들 간의 의존성이 생긴다. 이러한 의존성은 단위 테스트를 작성을 어렵게 하는데, 이를 해결하기 위해 가짜 객체를 주입시켜주는 Mockito 라이브러리를 활용할 수 있다. Mockito를 활용하면 가짜 객체에 원하는 결과를 Stub하여 단위 테스트를 진행할 수 있다. 물론 Mock을 하지 않아도 된다면 하지 않는 것이 가장 좋다.

[ Mockito 사용법 ]

1. Mock 객체 의존성 주입

Mockito에서 Mock(가짜) 객체의 의존성 주입을 위해서는 크게 3가지 어노테이션이 사용된다.

• @Mock: Mock 객체를 만들어 반환해주는 어노테이션
• @Spy: Stub하지 않은 메소드들은 원본 메소드 그대로 사용하는 어노테이션
• @InjectMocks: @Mock 또는 @Spy로 생성된 가짜 객체를 자동으로 주입시켜주는 어노테이션

예를 들어 UserController에 대한 단위 테스트를 작성하고자 할 때, UserService를 사용하고 있다면 @Mock 어노테이션을 통해 가짜 UserService를 만들고, @InjectMocks를 통해 UserController에 이를 주입시킬 수 있다.

2. Stub로 결과 처리

앞서 설명하였듯, 의존성이 있는 객체는 가짜 객체(Mock Object)를 주입하여 어떤 결과를 반환하라고 정해진 답변을 준비시켜야 한다. Mockito에서는 다음과 같은 stub 메소드를 제공한다.

• doReturn(): Mock 객체가 특정한 값을 반환해야 하는 경우
• doNothing(): Mock 객체가 아무 것도 반환하지 않는 경우(void)
• doThrow(): Mock 객체가 예외를 발생시키는 경우

3. Mockito와 Junit의 결합

Mockito도 테스팅 프레임워크이기 때문에 JUnit과 결합되기 위해서는 별도의 작업이 필요하다. 기존의 JUnit4에서 Mockito를 활용하기 위해서는 클래스 어노테이션으로 @RunWith(MockitoJUnitRunner.class)를 붙여주어야 연동이 가능했다. 하지만 SpringBoot 2.2.0부터 공식적으로 JUnit5를 지원함에 따라, 이제부터는 @ExtendWith(MockitoExtension.class)를 사용해야 결합이 가능하다.

 

단위 테스트 작성 예시 : https://mangkyu.tistory.com/145

 

---

참고 : 

테스트 작성 가이드

[Java] JUnit을 활용한 Java 단위 테스트 코드 작성법 (2/3)

TDD(Test-Driven-Development) 방법론

코드리뷰의 A-Z: Pull Request에서 Code Review까지

https://scshim.tistory.com/175

https://mangkyu.tistory.com/143

https://mangkyu.tistory.com/145