테스트 커버리지 100% 달성 후기

  이 글은 테스트 커버리지 100%를 달성하는 과정과 그 과정에서 느낀 점을 기록한 글입니다.

 

📚 1. 계기

  아래 2가지 이유와 함께 '테스트 커버리지 100%를 달성해 보자!'라는 목표가 생겼다.

📗 1. 로버트 C. 마틴(a.k.a Uncle Bob)의 클린 코더

  클린 코더에 다음과 같은 내용이 있다.

로버트 C. 마틴

얼마만큼의 코드를 자동화한 단위 테스트로 계산해야 할까?
대답할 필요조차 없다. 모조리 다 해야 한다. 모. 조. 리!
100% 테스트 커버리지를 권장하냐고?
권장이 아니라 강력히 요구한다. 작성한 코드는 한 줄도 빠짐없이 전부 테스트해야 한다.
군말은 필요 없다.
                                                                                                                  - 클린 코더 (로버트 C. 마틴 저) - 

  개발자가 아닌 사람이 위의 내용을 본다면 '너무 당연한 거 아니야?'라고 생각할 거 같다. 하지만, 개발자가 해당 내용을 본다면 '권장이 아니라 필수라고?' 생각할 것이다.

  이러한 놀라움과 함께 바로 테스트 커버리지 100%에 도전한 것은 아니지만, 계속해서 그 중요성에 대해서는 생각하고 있었다.

 

📗 2. 토스 유튜브

  두 번째 계기는 토스ㅣSLASH 21 - 테스트 커버리지 100%다.

  영상에서는 테스트 커버리지 100%를 달성하고 유지하면서 배운 것들(높은 테스트 커버리지의 이점, 테스트 코드 작성에서의 문제점과 해결책,...)에 대해서 소개하고 있다. 약 2년이라는 시간 동안의 기록이기 때문에 내용 자체가 알차고 재밌었다.

  영상을 다 보고 난 후, '토스라는 큰 회사에서도 테스트 커버리지 100%를 달성하는데 내가 하는 프로젝트에서도 충분히 할 수 있지 않을까?'라는 생각을 하였다. 그렇게 '테스트 커버리지 100% 달성'이라는 여정이 시작되었다.🛫

 

📚 2. 준비

  '테스트 커버리지 100%를 달성해 보자!'라는 생각과 함께 아래 3가지를 준비하였다.

📗 1. 테스트 작성 방법 학습

  첫 번째 준비는 테스트 작성법을 학습하는 것이다.

TDD, BDD 등에 대한 개념은 알고 있었지만, 프로젝트에서 제대로 된 테스트를 작성해 본 경험이 없었을 뿐만 아니라 테스트 작성 방법을 따로 공부한 적이 없었다. 그래서 박우빈 님의 'Practical Testing: 실용적인 테스트 가이드' 강의를 통하여 테스트 작성법을 학습하였다.

Practical Testing: 실용적인 테스트 가이드 - 인프런 | 강의

강의를 통해 

• 기본적인 테스트 코드 작성법
• TDD
• BDD
• 레이어드 아키텍처에서의 테스트 작성법
• Mock 사용법
• 시나리오 테스트

등을 학습할 수 있었다.

 

  강의에서 다양한 테스트 작성 방법뿐만 아니라 테스트 작성 시 유용한 팁도 많으므로 혹시나 테스트 가이드에 대해서 알고 싶다면 이 강의를 적극 추천한다!!

 

📗 2. JaCoCo 세팅

  두 번째 준비는 JaCoCo 세팅이다. JaCoCo는 Java 코드의 커버리지를 체크하는 라이브러리다.

 

  JaCoCo를 활용한다면 테스트를 하지 않은 부분 또는 테스트 작성 시 놓친 부분을 위와 같이 손쉽게 확인할 수 있다.

  또한, JaCoCo를 이용하여 다음과 같은 설정들을 할 수 있기 때문에 자신이 원하는 형태로 테스트 환경을 구축할 수 있다.

- 커버리지를 체크할 단위(클래스, 메서드, 패키지,...)
- 코드 커버리지를 측정할 때 사용되는 지표(코드 라인 수, 조건문 등의 분기 수, 클래스 수, 메서드 수,...)
- 테스트 실행 시 자동으로 JaCoCo 실행
- 테스트에서 제외할 클래스 설정
-...

 

아래의 글을 참고한다면 Gradle 프로젝트에서 JaCoCo 세팅을 손쉽게 할 수 있을 것이다.

Gradle 프로젝트에 JaCoCo 설정하기 | 우아한형제들 기술블로그

 

📗 3. 프로젝트 준비

  테스트 케이스를 작성하려면 프로젝트가 필요했다. 프로젝트는 SSAFY에서 진행한 공통 프로젝트를 활용하였다. 개발 기간은 약 4주 정도였으며, 인스트럭션(instruction, 자바 바이트코드 명령 수)이 약 3,300개 정도인 프로젝트다.

 

📗 4. 다짐

  마지막으로 준비할 것은 다짐이다. 시작하기 전에 어느 정도 어려울 것이라고 예상을 하였다.

  음... 회고를 적고 있는 이 시점에 다시 한번 생각해 본다면, '테스트 코드 작성의 어려움'뿐만 아니라 '테스트 코드 작성을 위한 시간, 노력, 장인정신'에 대해서도 한번 생각해 봤으면 어땠을까 싶다. 😅

 

📚 3. 문제점

  테스트 커버리지 100%를 달성하는 과정에서 겪은 어려움은 다음과 같다.

📗 1. 테스트 코드 작성 자체의 어려움

  기능 구현 코드가 항상 깔끔한 것은 아니었기 때문에 그러한 기능 구현 코드를 기반으로 테스트 코드를 작성하는 것에도 어려움이 있었다.

  나를 포함하여 3명의 백엔드 개발자 모두가 배우고 있는 입장이라서 좋은 기능 구현 코드를 항상 짤 수 있는 것은 아니었다. 알고 있는 범위에서 최대한 좋은 코드를 작성하려고 하였지만, 여전히 낮은 응집도와 높은 결합도를 가진 코드들이 많았다. 😥

  그렇게 실력에서 오는 아쉬움과 함께 테스트 코드를 작성하였다. 대부분의 코드에 대해서는 어느 정도 깔끔한 테스트 코드를 작성할 수 있었다. 하지만, 조금이라도 문제점이 있는 코드에 대해서는 기능의 단위가 상대적으로 너무 커서 테스트 코드를 작성하는데 시간이 많이 들어갔다.

  물론 테스트 코드를 기반으로 리팩토링도 진행하였다. 리팩토링을 하면서 메서드를 분리하고 그것을 기반으로 다시 테스트 코드를 작성하였지만 여전히 부족함이 있었다. 이 부분이 제일 아쉽고 속상한 부분이었지만, 더 열심히 공부해야겠다는 의지를 불태운 순간이기도 하다.🔥

 

📗 2. 테스트 코드 작성에 대한 경험 부족

  박우빈 님의 테스트 코드 강의를 통해 'Presenatation Layer 테스트, Business Layer 테스트, Persistance Layer 테스트, Mock 사용법' 등 다양한 테스트 방법을 학습하였다.

  그러나 실제 테스트를 하는 과정에서 'Spring Security'와 관련된 설정해야 하는 등 더 다양한 상황들이 많았다. 하나하나 찾아보면서 문제들을 해결하였지만, 아무래도 처음이라서 그런지 시간이 많이 걸렸다.

 

📗 3. 유지의 어려움

  이어지는 내용에서 확인할 수 있듯이 일단은 테스트 커버리지 100%를 달성하긴 했다. 하지만, 계속해서 테스트 커버리지 100%를 유지할 수 있는지에 대해서는 의문이 든다.

  기능 구현 코드를 작성한 사람이 그에 해당하는 테스트 코드를 작성하는 것이 좋다고 생각한다. 그러나 때로는 부족한 부분(커버리지가 충분하지 않은 경우)에 대해서 다른 사람이 테스트 코드를 추가해주어야 하는 상황이 생기기도 한다. 하지만, 다른 사람의 코드를 이해하고 더 나아가서 테스트 코드 작성하기 위해서는 시간과 노력이 많이 들어간다는 문제점이 있다.

  위의 예시뿐만 아니라 더욱 다양한 상황 속에서 과연 테스트 커버리지 100%를 계속 유지할 수 있을까라는 생각이 든다. 물론 테스트 커버리지 100%가 아니면 배포 자체가 안되도록 강제하는 방법을 통해 시스템을 유지할 수 있겠지만, 그것이 좋은 해결책은 아니라고 생각한다.

  개인적으로 그리고 팀적으로 테스트 커버리지 100%를 유지하기 위한 동기와 규칙이 존재해야 한다고 생각한다.

 

📚 4. 성과 (얻은 점)

📗 1. 테스트 커버리지 100% 달성

  가장 큰 성과는 아무래도 '테스트 커버리지 100% 달성'이다.

  100%를 달성하기 위해 231개의 테스트 케이스를 작성하였다.

  만약에 90%라는 목표를 세웠다면 테스트하기 쉬운 것들 위주로 테스트를 작성하여 90%를 달성하였을 것이다. 하지만, 100%를 달성하기 위해서 테스트하기 어렵고 시간이 많이 걸리는 것들까지 모두 테스트 코드를 작성해야 했다. 이러한 과정에서 다양한 상황에서의 테스트 코드 작성 방법을 익힐 수 있었다. 또한, 책에서만 보던 실용주의 철학(실용주의 프로그래머 - 데이비드 토머스, 앤드류 헌트 지음)을 조금이나마 실천해 볼 수 있는 좋은 기회였다.

 

📗 2. 클린코드 작성

  이번 프로젝트를 통해서 조금 더 나은 코드들을 작성할 수 있었다.

  더 나은 테스트 코드를 작성하기 위해서 더 신경을 써서 기능 구현 코드를 작성하였다. 그리고 테스트 코드를 기반으로 리팩토링을 진행하여 한번 더 코드를 개선하였다. 이러한 작업을 통해 이전까지 했던 프로젝트와 달리 조금 더 개선된 코드들을 작성할 수 있는 시간이었다.

 

📗 3. 실제로 체감한 개발 속도 향상

  '테스트가 가능한 안전한 환경에서 개발을 진행하면 개발 속도가 증가한다.'라는 말을 들어본 적이 있을 것이다. 하지만, 프로젝트를 해보면 알겠지만 기능 구현에 급급해서 테스트 코드를 꾸준히 작성하는 게 쉽지만은 않다.

(단순히 귀찮아서라기보다는 일정이란 게 있고 문제가 계속 생기는 상황에서 항상 테스트를 작성하는 것은 정말 어려운 거 같다... 물론 실력을 더 쌓아서 이러한 것도 다 관리해야 할 것이다!!)

  하지만, 이번 프로젝트에서는 굳게 마음을 먹고 테스트 코드를 작성하면서 개발을 하였다. 초반에는 테스트 코드 작성 때문에 시간이 많이 걸렸다. 하지만 후반으로 갈수록 안전한 환경에서의 과감한 기능구현과 리팩토링 덕분에 더욱 빠르게 개발을 진행할 수 있었다.

(물론 테스트를 과하게 작성한다면 개발 속도가 느려지기도 할 것이다. 하지만 일반적으로는 테스트가 너무 많은 경우보다는 너무 적은 경우가 훨씬 많다고 한다.)

 

📚 5. 느낀 점

📗 "테스트 커버리지 100%가 안전성을 보장하지는 않는다."

100%라는 숫자를 보면서 다음과 같은 의문점이 있었다.

• 이게 정말 안전한 애플리케이션인가? 
• 100%가 의미하는 게 정확히 무엇이지?

  첫 번째 의문에 대한 답은 'NO'다. 두 번째 의문에 대한 답은 '100%는 내가 만든 확률'이라는 것이다. 결론적으로 테스트 커버리지 100%란 '내가 만든 상황에 대해서 내가 만든 대처 방법이 잘 작동하는지에 대한 것'이다.

  예를 들어, 다음과 같이 자신이 가진 식재료들을 이용하여 만들 수 있는 음식을 알려주는 기능이 있다고 해보자.

public class FoodIngredient {

  private Enum foodIngredientCategory;

  // 소비기한
  private LocalDate expirationDate; 

  ...
}

public Food getFoodBy(List<Ingredient> foodIngredients) {

  ...
  
  // 만들 수 있는 음식이 없는 경우 예외 처리
  if(...) {
    throw new Exception("만들 수 있는 음식이 없습니다.");
  }

  return foodMadeFromIngredients;
}

테스트 케이스는 다음과 같을 것이다.

• 식재료들을 이용하여 만들 수 있는 음식을 알려준다.
• 식재료들을 이용하여 만들 수 있는 음식이 없을 수 있다.

이렇게 테스트 케이스를 작성한다면 해당 기능에 대해서 테스트 커버리지는 100%가 나올 것이다. 그렇다면 안전한 서비스일까? 꼭 그런 것만은 아니다.

  식재료의 소비기한을 확인하지 않았기 때문에 상한 음식을 만들 수 있기 때문이다. 그렇기 때문에 아래와 같이 식재료의 소비기한을 확인한다면 더 안전한 서비스가 될 것이다.

public Food getFoodBy(List<Ingredient> foodIngredients) {

  ...

  // 식재료들의 소비기한 확인
  checkExpirationDate(foodIngredients)

  // 만들 수 있는 음식이 없는 경우 예외 처리
  if(...) {
    throw new Exception("만들 수 있는 음식이 없습니다.");
  }

  return foodMadeFromIngredients;
}

수정된 테스트 케이스는 다음과 같다.

• 식재료들을 이용하여 만들 수 있는 음식을 알려준다.
• 식재료들을 이용하여 만들 수 있는 음식이 없을 수 있다.
• 식재료의 소비기한이 지났다면 음식을 만들 수 없다.

  이처럼 테스트 커버리지가 100%라도 안전한 서비스가 아닐 수 있다.

  그렇다면 더 안전하고 더 나은 애플리케이션을 만들려면 어떻게 해야 할까? 그 답은 로그와 모니터링에 있다고 생각한다.

 

    다음 편에 계속... (실력을 더 쌓아서 오겠습니다😎)