테스트 네이밍

테스트를 할 때 테스트 클래스를 만들고 메소드를 만들어 테스트를 한다.

이 때 네이밍해야 할 요소는 크게 두가지이다.

• 테스트 클래스 이름
• 테스트 메소드 이름

단위 테스트라면 테스트 클래스의 이름은 테스트하고자 하는 클래스 이름 뒤에 Test를 붙이는게 일반적이다.

메소드의 경우 테스트하고자 하는 클래스의 public 메소드의 이름을 그대로 사용할 수 있다.

 

예시로 인자로 주어진 언어(Language)에 따라 다른 인사말을 반환하는 클래스가 있다.

public class Hello {

    public String hello(Language language) {
        if (language == Language.KOREAN) {
            return "안녕하세요";
        }
        return "Hello";
    }

    enum Language {
        KOREAN, ENGLISH;
    }
}

IntelliJ의 Create Test단축키(Cmd + Shift + T)를 사용하면 클래스명 + Test라는 테스트 클래스가 자동으로 생성된다. 또한 테스트할 public 메서드도 선택할 수 있다.

 

예제 클래스에서 Create Test 단축키를 사용했을 때의 모습이다.

위와 같은 네이밍으로 알 수 있는 정보는 '테스트 대상'일 것이다.

이것만으로 내가 하고자하는 테스트의 의미를 충분히 전달할 수 있을까?

 

테스트는 프로그래밍 관점에서 볼 것이 아니라 비즈니스 관점에서 봐야 한다.

위와 같은 네이밍으로 'Hello.class의 hello 메서드를 테스트 한다.'는 의미는 전달됐다. 👉 프로그래밍 관점

하지만 '언어에 따라 다른 인사말을 반환해야 한다.'는 의미는 전달되지 않았다. 👉 비즈니스 관점

 

그렇다면 어떤 내용을 더 담아야 비즈니스적인 내용을 테스트에 담을 수 있을까?

다음과 같은 내용이 추가로 필요한다.

• 주어진 상황에서
• 예상되는 결과

기존 네이밍에서 위 내용을 더하면

"Hello.class의 hello 메서드는 한국어가 주어졌다면, '안녕하세요'를 반환해야 한다."

라고 네이밍할 수 있다.

 

따라서 다음과 같이 테스트를 작성할 수 있다.

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

@DisplayName("Hello 클래스")
class HelloTest {

    @DisplayName("한국어가 주어졌다면, '안녕하세요'를 반환해야 한다.")
    @Test
    void givenKorean_whenHello_thenKoreanHello() {
        // given
        Hello.Language language = Hello.Language.KOREAN;
        Hello hello = new Hello();

        // when
        String koreanHello = hello.hello(language);

        // then
        assertThat(koreanHello).isEqualTo("안녕하세요");
    }

}

@Display의 장점 👇

@Display의 장점

 

한국어로 이름을 지으면 문제가 되지 않을까라는 걱정이 생긴다.

하지만 @Display를 사용하면 주석처럼 한국어를 사용하고 그 결과를 테스트 화면에서 볼수 있다!

 

@Display는 클래스와 메소드 레벨에 붙일 수 있다. 아래 @Target에 TYPE, METHOD라고 선언되어 있다.

@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Documented
@API(status = STABLE, since = "5.0")
public @interface DisplayName {

	String value();

}

위와 같이 작성하면 다음과 같은 장점이 생긴다.

1. 가독성 향상
   • 테스트 메서드 바디를 읽지 않아도 어떤 내용을 검증하는지 알 수 있다.
2. 문서화 가능
   • 비즈니스 요구사항이 코드에 드러나므로 이를 기준으로 개발을 할 수 있다.
3. 유지보수 용이
   • 테스트 실패 시 어떠한 비즈니스 요구사항을 만족시키지 못하는지 바로 알 수 있다.
   • 요구사항이 변경되면 어떤 테스트를 변경해야할지 바로 알 수 있다.

정리하면

• 테스트 이름은 비즈니스 내용을 담아야 한다.
• 테스트 이름에 비즈니스 내용을 담기 위해서는 테스트 대상, 주어진 상황, 예상되는 결과가 필요하다.

참고

Naming standards for unit tests - Roy Osherove

GivenWhenThen - Martin Fowler