JUnit5 - JUnit 환경 세팅과 첫 번째 테스트 케이스 작성

 

💬 <자바와 JUnit을 활용한 실용주의 단위 테스트> 책을 통해 공부한 내용을 정리하였다.

 

첫 번째 JUnit 테스트 만들기 (p26 ~ p39)

💬 책에 나와있는 코드를 직접 작성하면서 공부하기 위해 IntelliJ에서 java 11 버전의 gradle 프로젝트를 생성했다. 책의 예제에서는 java 8의 stream을 사용하므로 연습용 프로젝트의 jdk도 8 이상을 사용하는 것이 좋다.

 

테스트 대상 코드

다음은 테스트 대상 코드이다.

 

📄 Scoreable.java

@FunctionalInterface
public interface Scoreable {
    int getScore();
}

 

✏️ 참고 - @FunctionalInterface
@FunctionalInterface는 함수형 인터페이스임을 가리키는 애노테이션이다.
함수형 인터페이스는 오로지 하나의 추상 메소드를 갖는 인터페이스이다.
자바 API에서 제공하는 함수형 인터페이스로는 Comparator, Runnable 등이 있다.
@FunctionalInterface를 붙였지만 실제로 함수형 인터페이스가 아니면, 즉 추상 메소드가 1개를 초과하면 컴파일 에러가 발생한다.

 

📄 ScoreCollection.java

public class ScoreCollection {

    private List<Scoreable> scores = new ArrayList<>();

    public void add(Scoreable scoreable) {
        scores.add(scoreable);
    }

    public int arithmeticMean() {	// 산술 평균
        int total = scores.stream().mapToInt(Scoreable::getScore).sum();
        return total / scores.size();
    }
}

 

ScoreCollection의 add() 메소드는 Scoreable 인스턴스를 인자로 받고, Scoreable 인터페이스는 int형 score 값을 반환한다.

💬 arithmetic mean이라는 어휘가 익숙하지 않아 사전 검색을 해봤더니 '산술 평균' 이라는 뜻이였다. 메소드 우측에 주석으로 추가하였다.

 

의존성 설정 및 테스트 환경 검증

프로젝트에 JUnit을 사용할 수 있도록 세팅하고 확인해보자.

 

ScoreCollection의 JUnit 테스트 클래스를 생성한다.

JUnit 버전은 책에서는 4를 사용하지만 내 실무 환경에서는 5를 많이 사용하고 더 편리하기 때문에 5로 선택했다.

이를 위해 프로젝트의 의존성 설정을 JUnit5를 가져오도록 변경해주었다.

그리고 AssertJ의 assert문을 사용하기 위해 assertj-core도 추가하였다.

 

📄 build.gradle

dependencies {
    testCompile group: 'org.junit.jupiter', name: 'junit-jupiter-api', version: '5.7.2'
    testImplementation group: 'org.assertj', name: 'assertj-core', version: '3.20.2'
}

 

테스트 클래스는 src/test 하위에 생성한다.

 

📄 ScoreCollectionTest.java

import org.junit.jupiter.api.Test;

import static org.junit.jupiter.api.Assertions.fail;

class ScoreCollectionTest {

    @Test
    void test() {
        fail("Not yet implemented.");
    }
}

JUnit은 @Test 애노테이션이 붙은 메소드를 테스트로 실행한다. 테스트 클래스에는 @Test가 붙지 않은 일반 메소드도 포함할 수 있으며 JUnit은 그러한 일반 메소드은 알아서 테스트 실행을 제외한다.

 

🖥 실행 결과

fail() 메소드에 의해 무조건 실패하는 테스트 메소드이다.

AssertionFailedError 익셉션이 발생하고 예외 메시지로서 fail() 메소드에 인자로 넘긴 "Not yet implemented."가 콘솔에 찍히는 것을 볼 수 있다.

 

📄ScoreCollectionTest.java

@Test
void test() {
//    fail("Not yet implemented.");
}

fail() 호출을 제거하면 테스트 메소드는 아무것도 검증하지 않으므로 무조건 성공한다.

 

🖥 실행 결과

 

이렇게 무조건 실패하는 테스트, 무조건 성공하는 테스트를 실행해서 올바른 결과가 나오면 JUnit을 사용할 준비가 된 것이다.

 

테스트 케이스 작성

테스트 케이스란 타겟 코드에 대한 기대 행동을 제공하는 시나리오이다.

작성할 테스트 케이스는 ScoreCollection의 멤버 리스트 scores에 정수 5, 7을 추가하고 arithmeticMean() 메소드가 6을 반환하는지 확인하는 것이다.

기존에 JUnit이 제대로 실행되는지 확인하기 위해 작성했던 의미없는 테스트 메소드는 삭제하고 아래와 같이 테스트 케이스를 작성한다.

 

📄 ScoreCollectionTest.java

import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

import static org.assertj.core.api.Assertions.assertThat;

class ScoreCollectionTest {

    @DisplayName("두 수의 산술 평균 성공 테스트")
    @Test
    void arithmeticMeanOfTwoNumbers() {
        // given
        ScoreCollection scoreCollection = new ScoreCollection();
        scoreCollection.add(() -> 5);
        scoreCollection.add(() -> 7);

        // when
        int actual = scoreCollection.arithmeticMean();

        // then
        assertThat(actual).isEqualTo(6);
    }
}

JUnit5를 사용해서 public을 생략하고 @DisplayName 애노테이션을 이용해 테스트 케이스의 내용을 더욱 명시적으로 작성할 수 있다.

assertThat()은 AssertJ의 메소드를 static import 하여 사용하였다.

 

책에서는 이 첫 번째 테스트를 준비, 실행, 단언 단계로 나누어 설명하였다.

그 보다 익숙하고 많이 사용되는 용어는 given, when, then 인 것 같다.

 

given - 준비 단계
테스트 상태를 설정하는 준비 단계
ScoreCollection 인스턴스를 생성하고 람다식으로 Scoreable을 넘겨 add()를 두 번 호출한 것이 이 단계이다.

when - 실행 단계
검증하려는 코드를 실행하는 단계
ScoreCollection의 arithmeticMean()을 호출하였다.

then - 단언 단계
기대하는 결과를 assert(단언)하는 단계
AssertJ의 assertThat()에 실제 나온 결과값 actual을 넘기고, 체이닝 메소드로 isEualTo()에 기대값인 6을 넘겨 호출하였다.

 

🖥 실행 결과

 

이 테스트 케이스가 실패하도록 변경해보자.

 

📄 ScoreCollectionTest.java

...
// then
assertThat(actual).isEqualTo(100);
...

 

🖥 실행 결과

기대값은 100이나 실제 결과값은 6이라는 메시지가 콘솔에 찍힌다.

 

아래와 같이 assert문을 바꿈으로써 테스트가 성공하도록 바꿀 수도 있다.

 

📄 ScoreCollectionTest.java

...
// then
assertThat(actual).isNotEqualTo(100);
...

 

🖥 실행 결과