[TDD] 자바 테스트 코드, 단위 테스트, 테스트하기 어려운 부분 (feat. 자동차 경주 게임)

우테코 수업 들었던 내용 중에서 간단하게 내 생각을 정리하고 싶어서 작성하는 글!

 

---

✨ 테스트 코드의 범위

테스트 코드는 어느 정도로 작게 만들어야 될까 고민을 많이 했다. 사실 이전에는 테스트 코드를 거의 작성한 경험도 없고, given-when-then만 구구절절 알고 있었어서 테스트 코드의 범위까지도 제대로 생각해 본 적 없었다. (와 진짜 자랑이다!)

개인적인 생각으로 테스트 코드는 해당 객체의 public 메서드에 대해서는 전부 테스트를 하는 게 맞다고 생각한다. 물론, private 메서드는 public에서 호출해서 간접적으로 테스트 할 수 있도록 만드는 것이 좋다고 생각한다.

 

초반에 페어 프로그래밍을 진행할 때, private 메서드를 테스트하려고 리플랙션까지 써가면서 진행했다.

우선, Cars의 경주에 대한 메서드이다. Cars는 Car에 대한 일급 컬렉션 객체이다.

요거는 Car의 움직임에 대한 메서드이다.

지금 보니까 진짜 이게 뭐지...? 라는 생각밖에 안 든다. 사실 이번 과제에서 핵심 도메인 로직인 '자동차 전진'에 대한 것인데, 내부에서 랜덤 넘버를 생성해주면서 이에 대해서 테스트가 하기 힘든 것이었다. 그래서 저렇게 리플랙션을 통해 접근하고, 직접적으로 코드를 넣어주는 식으로 진행을 하게 된 것이다. (물론 절대 이렇게 하면 안 된다.) 오른쪽 역시 우승한 자동차를 뽑는 것인데,  내부적으로 위치가 세팅되어 있는 자동차를 얻어올 수가 없어서 저런 식으로 직접 필드에 값을 세팅해주는 식으로 진행했다. 

당연히 리뷰도 이렇게 받을 수밖에 없었다. 내 문제는 크게 2가지였다.

1. 도메인에 대한 역할과 책임을 제대로 나누지 않은 것

2. 테스트하기 어려운 부분에 대해서 분리하지 않은 것.

 

특히 1번은 정말 중요한 부분이었다. 리뷰어님이 말씀해주신 것처럼, car가 움직이는지, 움직이지 않은지에 대한 테스트를 굳이 cars까지 생성하면서 진행할 필요가 전혀 없었기 때문이다. 

이때 단위 테스트에 대해서 다시 생각해보는 계기가 된 것 같다. 기존에는 Cars에서 random number에 대해서 자동차를 움직일지 말지 판단하도록 했지만, Car에게 매개변수로 해당 값을 넘겨주고 객체가 직접 움직일지 말지 판단하는 식으로 구현하였다. '객체에게 질문하라.' 라는 것을 제대로 깨달을 수 있었다. 그래서, 코드를 다음과 같이 수정하였다.

이 덕분에 테스트 코드도 이렇게 간단해졌다. 정확하게 해당 자동차의 움직임에 대해서만 판단하는 진정한 '단위 테스트'가 된 것이다.

 

아무튼, 말이 조금 샌 것 같지만 단위 테스트는 해당 객체의 행위의 책임을 명확하게 설계한 상태로, 해당 객체의 한 가지 기능에 대해서만 테스트하는 것이라고 생각한다. 만약 단위 테스트가 지나치게 복잡해진다면, 객체의 설계를 다시 수정할 필요가 있다. 객체는 무조간 한 번에 한 가지 일만 하도록 하자는 것!

 

---

✨ 테스트 메서드의 네이밍

이거는 페어랑도 얘기 나눴던 부분이고, 네오가 수업 중에 언급도 해주신 부분이었다. 사실 나 같은 경우 테스트 메서드 역시 given-when-then으로 선언하는 것을 선호한다. 기본적으로 메서드의 네임은 해당 메서드가 무슨 일을 하는지 이름만 보고도 넘어갈 수 있을 정도로 잘 표현하고 있어야 한다고 생각하기 때문이다. 그러나, @DisplayName 어노테이션이 존재하기 때문에 몇몇 분들은 굳이 그렇게 작성할 필요가 없다고 하셨다. 물론 맞지만, 화면에 띄워지는 이름은 해당 메서드가 무슨 일을 하는지 서술하듯이 풀어쓰는 공간이라고 생각하고, 여러 개의 테스트를 돌렸을 때 (Intellij IDEA로 빌드 시) 해당 테스트에 대해 한 눈에 확인하는 용도 정도라고 생각한다. 나는 메서드 네임으로 기본적으로 해당 메서드에 대해 판단할 수 있어야 한다고 생각하기 때문에 네이밍이 중요하다고 생각하는 쪽에 작게 한 표를 던지고 싶다.

 

---

✨ 단위 테스트

단위 테스트 시 중요한 건 첫 번째로, 테스트할 적당한 값을 찾는 것이다. 무작정 아무 값이나 테스트하는 것이 아니라는 점이다. 1~100까지의 100개의 테스트를 진행하는 것보다, 경계값에 대해서 테스트를 진행해주는 것이 더 좋다고 생각한다.

 @ParameterizedTest
@ValueSource(ints = {0, 3})
@DisplayName("랜덤값이 3 이하면 자동차가 정지한다.")
    void givenThreeLessNumber_thenCarStop(int randomNumber) {
            // given
            int initPosition = car.getPosition();

            // when
            car.move(randomNumber);

            // then
            assertThat(car.getPosition())
            .isEqualTo(initPosition);
            }

나 같은 경우 자동차 정지에 대한 테스트를 다음과 같이 0, 3에 대해서만 테스트를 진행하였다. 도메인 제약 사항이 0~9 사이의 값에 대해서 판단이 되기 때문에, 정지에 대해서는 0~3, 움직임에 대해서는 4~9에 대해서 진행하였다. 이렇게 범위 내에서의 최소, 최대값을 넣어서 테스트를 하는 것이 중요하다.

 

두 번째로는, 내가 어떠한 로직을 테스트할 것인지 판단하는 것이다. 이전의 나쁜 코드 (= 내 코드)를 본 것처럼, 자동차를 움직이는 것에 대한 테스트를 진행하는데 굳이 cars를 생성하면서까지 테스트를 할 필요가 없다는 것이다. 개인적으로 2가지를 생각하면 좋을 것 같다.

 

1. 어떤 객체의 책임인가?

2. 해당 객체의 어떤 행위를 테스트할 것인가?

 

이렇게 딱 2가지를 테스트 하는데 다른 객체가 필요하다면, 한 객체의 메서드가 여러 일을 하고 있는지 검증해봐야 한다. 물론! 단위 테스트의 이야기이다. 😄 그리고, 이렇게 작은 단위에 대해서 테스트를 진행하다 보면 이전에 테스트했던 항목과 비슷하게 테스트하는 경우가 발생해서 개발적으로도 오류에 대한 예측이 쉬워진다. 

 

간단하게 작성하려고 했는데 참 길어졌다. TDD는 다음 미션 진행하면서 더더 공부해보고자 한다! 더 깔끔한 코드를 위해서 파이팅...!