좋은 테스트를 작성하는 방법

단위 테스트 - YES24

테스트는 소프트웨어 프로젝트에서 빠지면 안되는 필수 요소이다.

하지만 컨트롤러에 있는 단 3줄의 코드를 위해 반복되는 테스트를 작성하고, 테스트에 필요한 복잡한 의존관계를 하나하나 만들다보면 무언가 잘못되었다는 신호를 몸으로 느끼게 된다.

 

테스트 코드를 작성하는 것은 누구에게나 재미없고 귀찮은 반복작업이다.

그럼에도 불구하고 테스트는 필요하다.

• 운영상에서 장애를 겪거나, 테스트를 작성했다면 하지 않았을 실수들
• 테스트를 작성하면서 넓어지는 설계에 대한 시야와 리팩토링 과정
• 새로운 기능을 추가할 때 기존 코드의 수정을 두렵지 않게 만들어주는 안전장치

 

💭 테스트의 목적

전용 프레임워크나 Mock 라이브러리를 잘 쓴다고 좋은 테스트인게 아니다. 오히려 테스트에 전혀 필요없을 수도 있다.

테스트를 작성함으로서 얻는 이득과 들어가는 노력을 항상 고려해야하고, 테스트에 드는 노력을 최소화 해야한다.

예를 들어 오래된 기존코드를 전부 뜯어가며 테스트를 추가하는 건 좋지않다. 이는 투자 대비 생산성이 전혀 없기 때문.

테스트 코드를 작성할 때 얻는 이득과, 거기에 들어가는 비용을 고려해야한다.

 

아래와 같은 조건의 기업용 앱을 작성할 때, 테스트의 효율을 극대화하려면 어떻게 작성해야할까?

• 높은 비즈니스 복잡도
• 긴 프로젝트 수명, 유지보수 기간
• 중간 크기의 데이터 관리
• 낮거나 중간 정도의 성능 요구

 

📑 무엇이 좋은 테스트를 만들까?

우선, 흔히 사용하는 코드 커버리지 100%는 좋은 테스트를 보장하지 않는다.

팀원간의 합의없이 무작정 높은 커버리지를 고집 부린다면, 아래와 같은 어이없는 테스트가 나올지도 모른다.

int add(int a, int b){
    return a - b;
}

@Test
@DisplayName("add 함수는 두 정수를 더해서 정수형으로 반환한다.")
void test(){
    // 커버리지를 억지로 채우기 위해서 전혀 검증되지 않는 테스트 코드를 작성한다.
    assertThat(add(0, 0)).isEqualTo(0);
    assertThat(add(1, 0)).isEqualTo(1);
}

우리는 테스트의 대상에 집중하고, 그 대상을 검증해야한다.

커버리지는 부정 지표로 사용해야한다. 너무 낮으면 확실하게 안좋은 코드지만, 높다고 무조건 좋은 건 아니다.   

병원에서 환자의 체온이 높으면 열이 난다는 것이고, 이 수치를 이용해 환자의 상황을 확인 할 수 있다.
그러나 '환자'가 아니라 '환자의 낮은 체온'이 목표가 되어버리면 절대 안된다.
약이나 치료는 치워버리고 당장 환자옆에 에어컨을 설치하는게 가장 좋은 코드가 되어버리기 때문이다.

 

결국 좋은 테스트라는 건

• 따로 시간내서 작성하는게 아니라, 개발 주기에 통합있어야 한다.
• 코드베이스에서 가장 중요한 부분(핵심 대상)만을 테스트 한다.
  테스트할 대상이 아닌 것 ➡ 인프라, 외부시스템(DB, 서드파티, 라이브러리), 모든 것을 하나로 묶는 통합코드
• 최소한의 유지비로 최대의 가치를 끌어내야 한다.
  아무런 검증도 하지않고, 어떠한 가치도 만들어 내지않는 코드. 그저 커버리지를 채우기 위한 테스트는 필요없다.

 

---

💭 단위 테스트

• 작은 코드 단위를
• 빠르게 테스트를 수행할 수 있고
• 격리된 방식으로 자동화하는 테스트

우리는 테스트하는 대상에 집중해야하고, 다른 외부의 문제가 영향끼치지 않게 격리해야한다.

객체지향을 사용하게 되면, 각각의 객체들은 서로 다른 의존성(협력)을 통해 문제를 해결한다.

 

테스트를 하겠답시고 모든 의존성을 다 만들순 없다. 의존성을 대신해줄 단위 테스트의 대역(Test Double)이 필요하다.
여담으로, 객체지향적인 코드는 테스트하기도 좋다. 구현 코드를 몰라도 다른 객체에 '메시지'를 보내면 되기 때문.

public class FakeObject {

    Map<Integer, Object> database = new HashMap<>();
    int count = 0;

    public Object get(int key) {
        return database.get(key);
    }

    public void save(Object data) {
        database.put(count++, data);
    }

    public int getCount(){
        return 10; // 테스트용 Stub 값
    }
}

 

좋은 테스트와 전혀 가치없는 테스트는 확실하게 구분할 수 있다.

내가 잘 하고있는건가 궁금하다면, 테스트를 작성할 때 아래의 특성을 잘 지키고 있는지 고려해보자.

• 회귀방지
• 리팩터링 내성
• 빠른 피드백과 유지보수성

 

📑 회귀방지

회귀는 일종의 소프트웨어 버그이다.

정확히는 새로운 기능을 추가했을 때, 의도한 대로 작동하지 않아 이미 완성된 코드를 수정하려고 돌아가는 것.

프로젝트가 커지면서 소프트웨어의 복잡도는 정말 빠르게 증가한다. 이러한 회귀를 방지하고자 미리 테스트 해야한다.

 

테스트를 통과했는데 기능은 고장나는 거짓음성(False Nagative)을 만들지 말자. 회귀하지 않도록 가능한 모든 경우를 테스트로 검증하자.

 

여기서 중요한 것은, `회귀하지 않도록` 테스트로 검증하는 것이다. 회귀 오류가 생길일이 없는 코드를 테스트하지는 말자. 예를 들어 User.getName() 처럼 아무런 로직이 없는 코드를 테스트하는 것은 아무런 가치가 없다.

 

 

📑 리팩터링 내성

테스트는 코드 리팩터링에 내성이 있어야한다.

새로운 기능을 추가했고, 모든 것이 잘 동작하는데 기존 테스트가 깨지면 안된다. 이러한 허위 경보는 테스트의 가치를 떨어뜨리고 결국 개발자는 테스트 수정을 피하기위해서 코드 변경을 최소화하려고 하게된다.

 

테스트가 리팩토링에 내성이 있으려면 어떻게 코드를 작성해야할까?

간단하다. 구현 세부사항이 아닌, 최종 결과를 테스트 목표로 삼으면 된다.

 

회귀방지에서는 가능한 모든 경우를 테스트하라고 했다. 그런데 여기선 하지말라고? 그게 아니다. 조금 더 생각해보자.

회원가입을 할 때 비밀번호의 PasswordEncoder 같은 내부 알고리즘이 바뀌었다고 테스트 결과에 영향이 있을까?

사실 테스트를 할 때 그 객체의 내부 동작까지 알 필요는 없다. 공개된 동작(api)을 실행하고, 그 결과만 확인하면 된다.

 

반대로 말하면, 구현의 세부사항이 변했을 때 테스트가 깨질 수 있다면, 괜찮아보이지만 잘못된 거짓양성(False Positive) 테스트가 아닌가 의심해야한다. [사실 리팩터링 내성은 프로젝트 초반에는 큰 문제가 되지 않는다.]

대부분의 경우 회귀방지는 알게모르게 하고있지만, 리팩터링 내성(거짓 양성)에는 둔감한 사람들이 많다.

그 이유는 프로젝트 초기에는 거짓양성이 큰 문제가 되지 않기 때문이다. 당장은 리팩토링하는게 더 쉬우니까.

 

하지만 프로젝트가 커지면 커질수록 리팩토링 내성은 중요해진다. 기능 고장이 아닌데도 테스트가 계속 깨지면서 테스트에 대한 신뢰를 잃게되고, 개발자는 의무감에 작성하는 가치없는 테스트를 계속 작성하게 된다.

 

 

📑 빠른 피드백과 유지보수성 

빠른 피드백 또한 단위테스트에서 매우 중요하다.

모든 의존성을 다 검사하는게 아닌, 그 대상만을 빠르게 검증하고 버그를 피드백함으로서 버그 수정비용을 크게 줄일 수 있다. 이미 충분한 검증을 했다면, 새로운 기능을 추가하더라도 기존 코드가 깨지지 않을까 두려워하지 않아도 된다.

 

비슷한 맥락으로, 단위테스트는 유지보수성이 좋아야 한다.

테스트를 이해하기 쉽고 외부 의존성없이 바로 실행하기 쉽게 만듦으로서 나중에 테스트를 추가하더라도 테스트의 유지보수가 쉬워진다. 

 

 

📑 이상적인 테스트는 3가지가 골고루 갖춰져야한다.

이 3가지는 따로 노는 개념들이 아니다.

있으면 좋고, 없으면 섭섭한 그런 요소들이 아니고 테스트에는 이 요소들이 다 골고루 갖추어져있어야 한다.

단위테스트와 통합테스트, 둘 다 해봐야합니다. 

 

#1. 극단적인 사례1 : E2E(End to End) 테스트

E2E는 최종 사용자 관점에서 모든 시스템을 사용하는 테스트를 의미한다.

이는 직접 작성한 코드를 포함하여 외부라이브러리, 프레임워크, DB등을 모두 테스트한다.
리팩토링 내성은 어떤가? 사용자 관점에서 테스트하기 때문에 내부구현을 전혀 알 필요가 없다. 결과만 검증한다.

• ✔ 회귀방지가 우수하다.
• ✔ 리팩토링 내성 또한 우수하다.

그럼 모든 테스트를 E2E로 만들면 최고일텐데 왜 그렇게 하지 못할까?

이유는 단순하다. 테스트를 준비하기가 매우 어렵고 모든 구현이 완료되어야 테스트가 가능하다.

즉, 피드백이 너무느리고 유지보수하기 어렵기 때문이다. 버그가 발생한다면 전체코드를 다시 뜯어봐야하고, 전체 동작을 한번에 검증하는거라 테스트를 추가하는 것도 매우 부담이 된다.

 

 

#2 극단적인 사례2 : 너무 간단한 테스트

피드백이 느리다고? 좋다 가능한 모든 것을 테스트해보고, 빠르게 피드백 받아보자

public class User {

    private String name;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

@Test
@DisplayName("User 객체에서 name을 조회하거나 변경할 수 있다.")
void Test() {
    // Arrange
    var sut = new User(); // sut => System under test, 테스트 대상 객체
    var string = "New User Name";

    // Act
    sut.setName(string);

    // Assert
    assertThat(sut.getName()).isEqualTo(string);
}

• ✔ 피드백 주기가 매우 빠르다.
• ✔ 내부 구현이 아니라 공개된 api만 테스트 하는 것이므로 리팩토링 내성 또한 그렇게 나쁘지 않다.

하지만 무언가 이상하다고 느껴진다. 아무런 가치도 없고 비슷한 테스트가 수백개는 반복된다. 이걸 왜 작성하는 걸까?

이는 테스트를 작성할 때  회귀 방지를 고려하지 않았기 때문이다. 테스트는 '회귀를 방지하기 위해` 작성해야한다. 전혀 회귀 오류가 발생하지 않을 것 같은 단순한 코드를 테스트 할 필요가 없다.

 

 

#3. 극단적인 사례3: 깨지기 쉬운 테스트

그럼 마지막으로 리팩토링 내성은 또 어떨까?

이는 위해서 언급했으므로, 간단하게 코드로만 살펴보고 넘어가도록 하자.

@Getter
public class UserRepository() {
    // 실제 Repository 객체
    private String lastExecutedSqlStatement();
}

@Test
@DisplayName("UserRepository 객체의 getById 메서드는 올바른 SQL문을 작성한다. ")
void Test() {
    // Arrange
    var sut = new UserRepository();

    // Act
    User user = sut.getById(5);

    // Assert
    Assertions.assertThat(sut.getLastExecutedSqlStatement)
        .isEqualTo("SELECT * FROM dbo.[User] WHERE UserId = 5");
}

만약 DB를 튜닝하게되어 SQL문이 변경되거나, 직접 쿼리를 작성하지않고 ORM을 사용하게 변경된다면 어떨까?

테스트는 핵심 대상을 테스트하는거지 내부 구현사항을 몰라도 큰 상관이 없다. 세부사항을 테스트하면 안된다.

 

회원가입을 하는데 DB나 passwordEncoder 알고리즘이 바뀌어도 동작에는 아무런 영향이 없다.

하지만 회원가입 테스트는 전부 실패할 것이다. 리팩토링 내성이 전혀 없는 테스트를 작성했기 때문이다.

 

 

💭 결론

말은 이렇게 했어도, 모든 조건을 완벽하게 충족하는 테스트를 작성하기는 쉽지 않다.

팁을 주자면 대부분의 기업용 프로젝트에서는 리팩터링 내성은 포기할 수 없다. 리팩터링 내성은 실제 서비스에 기능을 추가하는데 큰 영향을 끼치기 때문이다.

 

리팩토링 내성을 가장 중요하게 고려하고, 회귀 방지와 빠른 피드백을 적절하게 타협하는게 좋다.

다만 절충안을 선택하는거지, 위 극단적인 사례처럼 한쪽을 완전히 포기해서는 절대 안된다. 좋은 테스트는 언제나 3가지 요소를 다 고려해야한다.

E2E는 회귀방지에 유리하고, 단위테스트는 빠른 피드백과 유지보수에 유리하다.

 

 

테스트의 본질적인 목적을 잊지 말자.