테스트를 실행했는데 이해가 잘 되질 않네요..
TDD 방법을 적용해보기 위해 익숙하지 않은 단위 테스트를 구현하고 실제 코드를 구현했다. 초록색 체크만 확인하고 넘어갔는데 위 사진과 같은 괴상한 내용들이 적힌 테스트 실행 결과를 확인했다. 리뷰를 해주시는 코니는 일정한 패턴을 찾으라고 하셨고 찾다보니 BDD 라는 패턴을 찾을 수 있었다.
BDD 테스트 코드 작성 패턴
given, when, then은 테스트 로직에서 적용되는 패턴이라면 BDD는 코드의 설명에 집중되어 있다.
@Nested
@DisplayName("Describe") // ...메소드는
class 메소드_이름 {
@Nested
@DisplayName("Context") //만약 ...상황이라면
class 상황_설명 {
@Test
@DisplayName("It") // ....를 리턴한다.(예외를 발생시킨다)
void 행동_설명() {
//로직
}
}
}
위 코드를 보면 알겠지만 @Nested
를 적극적으로 활용하고 있다. 각 키워드의 예시로 작성을 해보면
@Nested
@DisplayName("isInPosition 메소드는")
class IsInPosition {
@Nested
@DisplayName("해당 위치에 있다면")
class Context_with_correct_position {
@Test
@DisplayName("true를 반환한다.")
void it_returns_true() {
Car car = new Car("car1");
assertThat(car.isInPosition(new Position(0))).isTrue();
}
}
@Nested
@DisplayName("해당 위치에 없다면")
class Context_with_incorrect_position {
@Test
@DisplayName("false를 반환한다.")
void it_returns_false() {
Car car = new Car("car1");
assertThat(car.isInPosition(new Position(1))).isFalse();
}
}
}
}
첫 번째 테스트 결과 창과 비교해본다면 훨씬 이해가 빠른 문장이 완성되었다. 작성을 할 때도 편했던 것이 항상 아래의 컨벤션을 유지해주면 된다.
@DisplayName
에 위처럼 컨벤션에 맞춰 작성하면 되고, 메서드 명은 크게 상관이 없기 때문에 자신이 쓰기 편한 방법과 일정한 패턴만 유지해서 작성하면 될 것 같다.
단점이라고 한다면 @Nested를 많이 쓰기 때문에 코드가 길어지고 타이핑이 많아질 수 있다.
Intellij의 라이브 템플릿 활용
반복적인 코드가 많기 때문에 고민을 하던 중, 라이브 템플릿이라는 기능을 알게되었다. psvm, sout 등 자주 쓰이는 코드들을 짧게 사용할 수 있도록 하는 명령어들이 있는데 이를 커스텀할 수 있는 기능이다. 참고에서 보면 쉽게 따라할 수 있고, 나는 bdd라고 치면 아래의 코드처럼 나올 수 있게 작성했다.
@Nested
@DisplayName("Describe")
class $METHOD_NAME$ {
@Nested
@DisplayName("Context")
class $INPUT_OR_CONDITION$ {
@Test
@DisplayName("It")
void $RETURN_OR_RESULT$() {
}
}
}