[우아한테크코스] 우테코 프리코스 6기 3주차 로또 미션 회고

개인적으로는 미션 수행을 통해 성장한 과정을 기록하고,
누군가에게는 이 글이 도움이 되었으면 하는 마음입니다 :)

🛠️ 3주 차 결과물

📮 3주 차 메일 내용

1️⃣ 3주 차 미션의 목표

2주 차 미션의 목표는 함수 분리와 함수별 테스트 작성이 목표였다. 그리고 이번 3주 차 미션에서는 2주 차에서 학습한 것에 더해 (1) 클래스(객체)를 분리하는 연습, (2) 도메인 로직에 대한 단위 테스트를 작성하는 연습이라는 두 가지 목표가 추가되었다.

2️⃣ 테스트 연습

아직까지 도메인 로직과 단위 테스트와 같은 용어들이 낯설 수 있지만, 일단 작은 기능부터 테스트를 작성하는 연습을 시작해 보기로 했다. 1주 차 피드백에서 제공된 숫자 야구 피드백 강의 후반부에 단위 테스트를 작성하는 내용이 있으니 이를 참고하라는 말도 있었다.

🌳 지난 2주 차 공통 피드백

아래는 2주 차 미션 마감 후, 모든 프리코스 참여 인원에게 발송된 공통 피드백이다. 엄청 의외의 내용이라기보다, 요구사항에 있는 내용들을 한번 더 강조하거나 추가로 학습할만한 내용이었다. 특히 이번 3주 차 미션에서 강조하듯 객체 분리 및 테스트 코드 작성에 관한 내용이 주를 이루었다.

1. README.md를 상세히 작성한다
2. 기능 목록을 재검토한다
3. 기능 목록을 업데이트한다
4. 값을 하드 코딩하지 않는다
5. 구현 순서도 코딩 컨벤션이다
6. 한 함수가 한 가지 기능만 담당하게 한다
7. 함수가 한 가지 기능을 하는지 확인하는 기준을 세운다
8. JavaScript에서 객체를 만드는 다양한 방법을 이해하고 사용한다.
9. 테스트를 작성하는 이유에 대해 본인의 경험을 토대로 정리해 본다
10. 처음부터 큰 단위의 테스트를 만들지 않는다

🤚 미션에 앞서,

1️⃣ 기능 목록 만들기

미션은 기능 요구 사항, 프로그래밍 요구 사항, 과제 진행 요구 사항 세 가지로 구성되어 있다. 특히 주목해야 할 점은 기능을 구현하기 전에 기능 목록을 만든다는 것. 기능 구현 시 목록을 만들어져 있는 것이 아니라, 직접 만들어야 하는 게 포인트다.

2️⃣ 제출 전 테스트 필수

기능 구현을 모두 정상적으로 했더라도 요구 사항에 명시된 출력값 형식을 지키지 않을 경우 0점으로 처리된다. 기능 구현을 제대로 했더라도 출력 값 형식을 지키지 않으면 0점이라는 소리다. 기능 구현을 완료한 뒤 테스트를 실행했을 때 테스트가 실패할 경우 0점으로 처리되므로, 반드시 확인 후 제출한다. 필자는 Node 환경에서 프로그램이 잘 돌아가는지 확인하고, 로컬 테스트 코드 통과까지 확인했다.

뿐만 아니라, 제출 가능 기간에는 미리 PR을 올리고 지원하기 플랫폼의 예제 테스트까지 미리 돌려보았다. 그렇지 않으면 마감이 몇 시간 남지 않은 상태에서 추측이 어려운 에러와 기약 없이 싸워야 하니 미리미리 확인하자.

3️⃣ Node 버전 확인 필수

테스트 패키지 설치를 위해 Node.js 버전 18.17.1 이상이 필요하다. 본인 로컬의 Node 버전이 몇인지 꼭 확인 후 미션을 진행하자. 참고로 Node 버전 확인은 'node --version'으로 확인 가능하며, 업데이트는 Node.js 공식 사이트를 참고하거나, 아래와 같이 'nvm install'로 특정 Node 버전을 설치할 수 있다.

🎱 기능 요구 사항

1️⃣ 로또 미션 설명

미션에 대한 자세한 내용은 우테코 프리코스 레포에 있으니 참고하길 바라며, 간단히 게임 설명을 하자면 사용자가 직접 당첨 번호를 입력하고, 구입한 로또 번호 중 당첨 조건에 따라 수익을 내는 게임이다.

여기서 잠깐, 현실에서의 로또와 미션 상에서의 로또 규칙은 아래와 같이 다르다.

🎱 현실 로또
👉 사용자는 로또 번호 직접 선택 or 랜덤
👉 당첨 번호는 무조건 랜덤 추첨

🎱 미션 로또
👉 사용자는 로또 번호 랜덤으로 수령
👉 당첨 번호를 직접 입력 필요

처음 이 미션을 접하면 헷갈릴 수 있다. 현실에서는 내가 당첨 번호를 절대 선택할 수 없는데, 미션에서는 사용자가 당첨 번호를 직접 입력할 수 있기 때문이다. 하지만 미션은 미션일 뿐. 현실에 대입하면 오히려 더 요구 사항에서 벗어날 수 있으니 많은 생각을 하지 말자. (마치 소금물 구하는 문제에서 왜 소금의 무게를 구하는지 의문을 품지 말아야 하는 것처럼..)

2️⃣ 로또 실행 결과 예시

구입금액을 입력해 주세요.
8000

8개를 구매했습니다.
[8, 21, 23, 41, 42, 43]
[3, 5, 11, 16, 32, 38]
[7, 11, 16, 35, 36, 44]
[1, 8, 11, 31, 41, 42]
[13, 14, 16, 38, 42, 45]
[7, 11, 30, 40, 42, 43]
[2, 13, 22, 32, 38, 45]
[1, 3, 5, 14, 22, 45]

당첨 번호를 입력해 주세요.
1,2,3,4,5,6

보너스 번호를 입력해 주세요.
7

당첨 통계
---
3개 일치 (5,000원) - 1개
4개 일치 (50,000원) - 0개
5개 일치 (1,500,000원) - 0개
5개 일치, 보너스 볼 일치 (30,000,000원) - 0개
6개 일치 (2,000,000,000원) - 0개
총 수익률은 62.5%입니다.

이번 미션 또한 지난 2주 차와 마찬가지로 (혹은 훨씬 더 꼼꼼하게) 사용자의 다양한 인풋을 예상하며 예외 처리를 했어야 했다. 요구 사항을 꼼꼼하게 읽지 않으면 놓치기 쉬운 것들이 많으니 더욱 꼼꼼하게 읽어보자.

아래 요구사항들을 아주 꼼꼼하게 씹어먹듯 읽어보자. (중요)

3️⃣ 로또 기능 요구 사항

✅ 로또 번호의 숫자 범위는 1~45까지이다.

👉 로또 번호의 숫자 범위는 1 이상 45 이하다. 이 말은 이 범위를 벗어나면 예외 처리를 꼭 해주어야 한다는 의미.

✅ 1개의 로또를 발행할 때 중복되지 않는 6개의 숫자를 뽑는다.

👉 1개의 로또에는 서로 중복되지 않는 6개의 숫자를 뽑아야 한다. 더불어, 각 로또 번호 구성이 중복되어서도 안된다.

✅ 당첨 번호 추첨 시 중복되지 않는 숫자 6개와 보너스 번호 1개를 뽑는다.

👉 (로또 번호가 아니라) 사용자가 당첨 번호를 입력하면 서로 중복되지 않는 숫자 6개, 그리고 보너스 번호 1개를 뽑는다. 이때 당첨 번호 간의 중복이 있어서도 안되고, 보너스 번호와 당첨 번호 간의 중복이 있어서도 안되니 예외 처리를 꼭 해주자.

✅ 당첨은 1등부터 5등까지 있다. 당첨 기준과 금액은 아래와 같다.

- 1등: 6개 번호 일치 / 2,000,000,000원
- 2등: 5개 번호 + 보너스 번호 일치 / 30,000,000원
- 3등: 5개 번호 일치 / 1,500,000원
- 4등: 4개 번호 일치 / 50,000원
- 5등: 3개 번호 일치 / 5,000원

👉 위의 출력 결과를 그대로 따르자. 되도록이면 그대로 복사 붙여 넣기 해서 상수화 하는 것이 좋을 것 같다. 또한, 5개 번호가 일치한다고 해서 모두 2등이 아니다. 2등은 5개 번호 그리고 보너스 번호까지 일치해야 한다.

✅ 로또 구입 금액을 입력하면 구입 금액에 해당하는 만큼 로또를 발행해야 한다.

👉 로또 게임 시작 시, 사용자가 구입 금액을 입력하는데 이때 구입 금액에 해당하는 만큼 로또를 발행해야 한다. 이 말은 즉, 구입 금액 / 로또 가격으로 나누어 로또 개수를 뱉어내야 한다는 말.

✅ 로또 1장의 가격은 1,000원이다.

👉 이 말은 사용자가 1,000원 이하를 입력하거나 1,000원으로 떨어지지 않는 수 (e.g. 1,200)를 입력하면 예외 처리를 해주어야 한다는 의미다.

✅ 당첨 번호와 보너스 번호를 입력받는다.

👉 당첨 번호와 보너스 번호는 랜덤으로 생성하는 것이 아니라 반드시 사용자에게 직접 입력을 받아야 한다. 이것이 바로 위에서 언급한 현실 로또와의 가장 큰 차이점이다. 지금 보니 당연한 요구 사항이긴 한데, 지금 보니 굉장히 중요한 문장인 것 같다.

✅ 사용자가 구매한 로또 번호와 당첨 번호를 비교하여 당첨 내역 및 수익률을 출력하고 로또 게임을 종료한다.

👉 사용자가 구매하고 랜덤으로 생성된 로또 번호, 그리고 사용자가 직접 입력한 당첨 번호 및 보너스 번호를 비교한다. 그리고 위에서 언급한 당첨 기준과 금액에 따라 결과를 출력한다. 더불어, 금액에 따라 수익률까지 계산한다. 이것이 아마 이 미션의 가장 핵심적인 로직이 아닐까 싶다.

✅ 사용자가 잘못된 값을 입력할 경우 throw문을 사용해 예외를 발생시킨다. 그런 다음, "[ERROR]"로 시작하는 에러 메시지를 출력하고 해당 부분부터 입력을 다시 받는다.

👉 정말 중요한 포인트. 이 포인트를 뒤늦게 봐서 테스트가 통과되지 않았던 적이 있다. 1, 2주 차에는 에러 메시지를 출력하고 즉시 애플리케이션을 종료했는데, 이번 미션부터는 해당 부분부터 다시 입력을 받아야 한다. 디스코드 커뮤니티를 지켜보니 이 부분을 꽤 많은 사람들이 놓치는 것 같았다. 정말 요구사항에 답이 다 나와있다!

🚨 프로그래밍 요구 사항 - 실행 환경

✅ Node.js 18.17.1 버전에서 실행 가능해야 한다.

👉 Node 버전 체크 필수다. 작업할 때 확인했더라도 제출하기 직전에 다시 한번 해당 버전에서 잘 돌아가는지 확인하자.

✅ 프로그램 실행의 시작점은 App.js의 play 메서드다.

👉 App.js로 게임을 실행할 수 있던 지난 1주 차와는 달리 2,3주 차는 App 클래스가 index.js에 import 되어 node 환경에서 index.js를 실행할 수 있었다. 매 미션마다 실행 환경이나 요구 사항이 완전히 똑같지 않을 테니 이미 알고 있는 것이라도 다시 읽어보는 것이 좋겠다.

✅ package.json을 변경할 수 없고 외부 라이브러리(jQuery, Lodash 등)를 사용하지 않는다. 순수 Vanilla JS로만 구현한다.

👉 1주 차 공통 피드백에 나와 있듯이 이제는 자연스럽게 ESLint와 Prettier를 사용한다. 그리고 변경된 package.json 내역은 굳이 push 하지 않았다.

✅ JavaScript 코드 컨벤션을 지키면서 프로그래밍한다.

👉 Airbnb 코드 컨벤션을 하나하나 보고 따르기에는 너무 번거로우므로 ESLint와 Prettier를 설정해서 컨벤션을 맞추었다.

✅ 프로그램 종료 시 process.exit()를 호출하지 않는다.

👉 보통 프로그램을 종료할 때 Console.Close()나 process.exit()를 사용하고는 했지만, 여기서는 메서드를 호출하지 않는다. 지난 1주 차 미션에서는 게임 종료 시 '게임 종료' 문구를 출력했고, 2주 차는 에러를 발생시키고 그대로 애플리케이션이 종료되도록 했다. 그리고 이번 3주 차는 해당 부분부터 다시 입력을 받는다.

✅ 프로그램 구현이 완료되면 ApplicationTest의 모든 테스트가 성공해야 한다. 테스트가 실패할 경우 0점 처리한다.

👉 이번 미션의 ApplicationTest는 총 3개의 테스트였고, 이 세 가지 테스트를 모두 통과해야 한다.

✅ 프로그래밍 요구 사항에서 달리 명시하지 않는 한 파일, 패키지 이름을 수정하거나 이동하지 않는다.

👉 디폴트로 있던 파일(package.json, package-lock.json 등)과 코드, 폴더는 굳이 건들지 않았다. 혹시나 지원 플랫폼 예제 테스트에 통과하지 못할까 봐 굉장히 조심스러웠던 것도 있다. 사실 src 폴더 바로 하위에 있던 Lotto.js를 src > model 폴더 하위에 두고 싶었으나.. 이 요구 사항을 보고는 그냥 둘 수밖에 없었다.

✅ indent(인덴트, 들여 쓰기) depth를 3이 넘지 않도록 구현한다. 2까지만 허용한다.

👉 이번부터 새롭게 추가된 요구사항이지만, 사실 함수 하나에 15줄 이상 넘어가고 depth가 많아지면 한 가지 일을 하지 않을 가능성이 높다. 따라서 indent depth를 줄이고자 한다면 함수 또는 메서드를 분리하면 된다. 더불어, 많은 이들이 depth에 대해 커뮤니티에 질문을 남겼는데, 예를 들어 while문 안에 if문이 있으면 들여 쓰기는 2이다.

✅ 함수(또는 메서드)가 한 가지 일만 하도록 최대한 작게 만들어라.

👉 공통 피드백을 비롯해 계속해서 강조하는 말이다. 함수가 뚱뚱해지지 않도록 신경 써야 한다.

✅ Jest를 이용하여 본인이 정리한 기능 목록이 정상 동작함을 테스트 코드로 확인한다.

👉 되도록 모든 메서드를 테스트하고자 했다. 특히 작은 단위는 꼭 테스트해서 추후 컨트롤러에서 터지면 안 되니까.

➕ 3주 차부터 추가된 요구사항

✅ 함수(또는 메서드)의 길이가 15라인을 넘어가지 않도록 구현하며, 함수(또는 메서드)가 한 가지 일만 잘하도록 구현한다.

👉 이 요구사항이 있어서 더 의식적으로 좋은 코드를 쓸 수 있게 된 것 같다. 더불어, 이는 아래와 같이 ESLint 상에서 설정하면 좋다.

// .eslintrc.cjs
'max-lines-per-function': ['error', { max: 15 }],

✅ else를 지양한다.

👉 if 조건절에서 return 하면 굳이 else를 사용하지 않아도 된다. 다만, 무조건적으로 지양한다기보다 때로는 if/else와 switch문을 사용하는 것이 더 깔끔해 보일 수 있어서 이는 고민해 보라고 한다.

✅ 도메인 로직에 단위 테스트를 구현해야 한다. 단, UI(Console.readLineAsync, Console.print) 로직에 대한 단위 테스트는 제외한다.

👉 여기서 중요한 건 핵심 로직을 구현하는 코드와 UI를 담당하는 로직을 구분한다는 것. 친절하게도 지난 2주 차와 마찬가지로 테스트 도구 사용법이 익숙하지 않은 사람들에게 예제로 주어진 LottoTest.js라는 파일이 주어졌다.

🚨 프로그래밍 요구 사항 - 라이브러리

✅ @woowacourse/mission-utils의 Random 및 Console API를 사용하여 구현해야 한다.

✅ Random 값 추출은 Random.pickUniqueNumbersInRange()를 활용한다.

✅ 사용자의 값을 입력받고 출력하기 위해서는 Console.readLineAsync, Console.print를 활용한다.

👉 1, 2주 차와 다른 점은 Random.pickNumberInRange()가 아니라, Random.pickUniqueNumbersInRange()를 활용해야 한다는 것이다. 이 메서드는 인자가 3개 들어간다.

✅ Lotto 클래스

👉 제공된 Lotto 클래스로 구현해야 하며, prefix 변경이나 필드 추가는 불가하다.

📚 미션을 통해 적용하고 배운 점

1️⃣ README 상세하게 작성하기

지난 2주 차 공통 피드백의 1번 사항 "README.md를 상세히 작성한다"를 준수하고자 했다. 물론 지난 미션들도 README 작성을 꼼꼼하게 한 편이지만, 매 미션을 거치면서 README에 무언가가 변경된다. (그만큼 학습하고 성장하고 있다는 뜻?) 필자는 공통 피드백을 아래와 같이 반영하고자 했다.

✅ 해당 프로젝트가 어떤 프로젝트이며, 어떤 기능을 담고 있는지 기술한다.

👉 본격적인 기능 구현 전에 어떤 프로젝트인지, 핵심적인 로직은 무엇인지 작성했다. 이를 통해 피드백이 그냥 피드백이 아니라고 생각했다. 확실히 프로젝트를 한 줄로 정리하니 더 이해가 잘 되었다.

✅ 기능 목록을 클래스 설계와 구현, 함수(메서드) 설계와 구현과 같이 너무 상세하게 작성하지 않는다.

👉 1주 차 때는 메서드 설계와 구현을 엄청 상세하게 적어두었는데, 그렇게 되면 문서 수정에도 꽤 시간을 썼어야 했다. 2주 차부터는 너무 세세한 부분까지 정리하기보다 구현해야 할 기능 목록을 정리하는 데 집중하고자 했다.

✅ 정상적인 경우도 중요하지만, 예외적인 상황도 기능 목록에 정리한다.

👉 정말 중요한 포인트! 지난 2주 차 때 나름 신경 썼다고 했지만 예외 처리 부분에서 스스로 아쉬움이 있었다. 이번에는 예외 처리만큼은 빈틈없이 해야겠다 생각했고, 예외 상황에 대한 출력 메시지까지 모두 정리해 두었다. 이렇게 정리해 두니 기능 테스트를 할 때 QA를 하는 것 같이 하나하나 상세하게 체크할 수 있었다.

✅ 기능 목록을 업데이트한다.

👉 처음부터 모든 기능 목록을 완벽하게 정리하기보다, 요구사항에 있는 것을 잘 정리해 둔다 라는 느낌이었고, 이후 기능 구현을 하면서 README도 수정해 나가며 살아있는 문서를 만들고자 했다.

✅ 그 외 작성한 것

👉 이번 3주 차 때 우테코 측에서 제시한 목표와 함께 스스로 2주 차보다 개선하고 싶은 것들을 적어서 구현하는 내내 잘 지키고 있는지 체크하기도 했다. 매주 실력이 똑같으면 안 된다. 뭔가 매주 더 나아져야 하기 때문이다.

2️⃣ 상수 컨벤션

지난 2주 차 때 상수 관련 Airbnb 컨벤션을 따르지 않아서 관련해 피드백을 받았고, 아래와 같이 3주 차 때 바로 반영해 보았다. 마침 2주 차 공통 피드백에서 "값을 하드코딩하지 않는다"라는 말이 있기도 했다. 더불어, 상수로 만드는 것뿐만 아니라 해당 변수의 역할이 무엇인지 네이밍에도 많은 고민을 했다.

Airbnb 컨벤션에 따르면, 아래와 같이 키는 대문자, 값은 소문자로 작성한다고 한다. 무의식적으로 상수는 무조건 대문자라고 생각했는데 이 부분을 한번 더 체크할 수 있어 좋았다.

// bad - unnecessarily uppercases key while adding no semantic value
export const MAPPING = {
  KEY: 'value'
};

// good
export const MAPPING = {
  key: 'value',
};

3️⃣ 메서드 세세하게 체크하기

지난 2주 차 코드리뷰에서 2~3가지 정도가 메서드에 대한 내용이었다. 대체로 필요하지 않은 것을 추가했다는 피드백이었다. 그래서 이번에는 괜히 분리해서 필요하지 않은 역할을 하는 메서드는 없는지 살펴보았다. 구현 초반에는 필요해 보이는 메서드를 일단 추가하고, 구현하면서 굳이 필요하지 않은 것들은 소거해 나가는 방식으로 진행했다.

4️⃣ 구현 순서

더불어, 2주 차에는 순서 없이 기능 구현을 했다면, 이번 3주 차에는 작은 메서드부터 작성했다. 아무래도 단위 테스트를 돌려야 했기에, 작은 단위부터 테스트 코드로 검증해 나가면 큰 단위의 테스트에서도 잘 돌아가지 않을까 싶어서였다.

그래서 유틸 함수(입출력, 유효성 검사) → 각 항목당 예외 처리 클래스 → 그리고 이 클래스를 컨트롤러에서 모두 합치는 방식으로 진행했다. 물론 요구사항이 애매하고 불확실한 상황에서는 큰 로직부터 짜고 필요한 함수들을 짜거나 유틸로 빼는 것이 좋기도 하겠지만, 요구사항이 확실한 상황이었기에 필요한 작은 함수들부터 만들어 나갔다.

import { LOTTO, ERROR } from '../common/constants.js';
import { throwError } from '../common/utils.js';

// 만들어 둔 유틸성 validator를 import 해오는 방식
import { isNumeric, isDivisibleByUnit } from '../common/validator.js';

// 구입 금액 유효성 검사 클래스
class MoneyValidator {
  constructor(input) {
    this.input = input;
  };

  validate() {
    this.#validateInput();
    this.#validateNumber();
    this.#validateMoneyUnit();
  };

// 공백이 있다면 에러 출력
  #validateInput() {
    if (!this.input) {
      throwError(ERROR.empty);
    }
  };

// 양의 정수가 아니라면 에러 출력
  #validateNumber() {
    if (!isNumeric(this.input)) {
      throwError(ERROR.numeric);
    }
  };

// 1000 단위로 떨어지지 않으면 에러 출력
  #validateMoneyUnit() {
    if (!isDivisibleByUnit(this.input, LOTTO.money_unit)) {
      throwError(ERROR.money);
    }
  };
};

export default MoneyValidator;

하지만 이는 3주 차 미션에 해당하는 이야기였고, 아마 4주 차부터는 핵심 로직을 작게 구현해 보면서 필요한 함수들을 그때그때 만들어 나가는 방식으로 시도해 볼 것 같다. (불확실한 문제를 푸는 데에는 최소 기능을 구현하는 MVP를 만들어 두고 하는 것이 낫지 않을까 생각해서다.) 어느 것이 더 좋은지는 이렇게 다양한 실험을 통해 직접 느껴보고자 한다.

5️⃣ 빈틈없는 구현

앞서 말한 것처럼 지난 2주 차 때 예외 처리 부분에서 스스로 아쉬움을 많이 느꼈기에 3주 차에는 이 부분을 톡톡히 신경 쓰고자 했다. 아래 2주 차 때 받은 피드백처럼 유효성 검사 메서드를 최대한 분리하고, 그에 맞는 에러 메시지를 출력하는 게 사용자 입장에서도 좋지 않을까 생각했다.

더불어, 예외 처리뿐만 아니라 요구사항을 읽고 또 읽으며 최대한 지키고자 노력했다. 자칫하면 빼먹을 수 있는 것들도 많았다. 예를 들어, 로또 번호는 공백이 오름 차순으로 나열된 배열 형태로 받는데 당첨번호는 공백 없는 문자열 형태로 받고, 수익률은 1000 단위로 쉼표를 찍고 소수점 둘째 자리에서 반올림을 한다든가. 동시에 이를 검증하는 테스트 코드 또한 꼼꼼하게 짜고자 했다.

현업으로 가면 더 고객과 접점이 많을 것이기에 다양한 인풋을 예상하고 예외 처리를 더 꼼꼼하게 해주어야 할 텐데, 우테코 덕분에 더 다양한 사용자의 인풋을 고려하고, 인풋에 따른 적절한 피드백을 주는 연습을 할 수 있었다.

6️⃣ 테스트 코드를 왜 작성해야 하는가

지난 2주 차 공통 피드백에서는 "테스트를 작성하는 이유에 대해 본인의 경험을 토대로 정리해 본다"라는 문장과 함께 학습 자료를 제공받았다. JUnit을 학습하며 작은 단위의 유닛 테스트부터 만들고자 했다.

더불어, 단위 테스트라는 것에 대해 궁금해 서칭해 보다가 아래의 테스트 피라미드라는 개념을 알게 되었다. 이 개념에서 설명하길, Unit 테스트는 독립된 작은 조각으로 테스트하고, Integration 테스트는 여러 가지 방법으로 그룹으로 결합되어 테스트한다고 한다.

이번 미션에서 요구하는 '단위 테스트'란 무엇인지 먼저 정의해 보자.

"단위 테스트란, 소프트웨어의 가장 작은 구성 요소, 가장 작은 코드 조각인 단위를 테스트하는 방법이다. 단위 테스트를 하는 목적은 각 장치가 제대로 작동하는지 확인하는 것이므로 다른 테스트와 독립적으로 동작을 테스트한다. 다시 말해, 테스트가 외부 시스템에 의존하는 경우 단위 테스트가 아닌 것이다. 궁극적으로는 단위들의 결함이 프로덕션 환경에 배포되는 것을 방지하기 위해 구현 전 설계 단계에서 작성되어야 한다는 것이다."

참고: Unit Testing @developerexperience

따라서 나는 이번 미션에서는 작은 단위의 함수나 모듈이 의도된 대로 정확히 작동하는지 테스트하고, 컨트롤러 테스트를 별도로 진행하지 않았다. 데이터베이스 연결 함수를 모킹화 하여도, 실제로 데이터베이스에 값을 넣는 것이 아니므로, 데이터베이스와의 연동에서도 제대로 테스트되는 것인지는 알 수 없기 때문이었다.

따라서 해당 함수에 테스트에 성공을 해도 실제 서비스의 실제 데이터베이스에서는 문제가 발생할 수 있다. 그럴 땐 유닛 테스트가 아닌, 통합 테스트나 시스템 테스트를 진행해야 할 것이다. (참고: [JEST] 📚 모킹 Mocking 정리)

개념을 공부하고, 테스트 코드와 함께 기능 구현을 하며 테스트를 작성하는 이유에 대해 아래와 같이 정리해 보았다.

일단 가장 좋은 이유는 "소스 코드에 대해 빠르게 피드백을 받을 수 있다는 것"이다. 사실 테스트 코드를 작성하지 않아도 되었던 1주 차 미션에서는 Integration 테스트만 하다 보니, 에러가 나면 어느 코드에서 누수가 되었는지 파악이 어려웠다. 반면, 테스트 코드를 작성한 2주 차와 3주 차에는 작은 단위의 메서드들부터 '이건 잘 됐어' '이건 잘못됐어'라는 피드백을 받으니 내 코드에 대한 신뢰도가 생겼다.

예를 들어, 공통 피드백에 "처음부터 큰 단위의 테스트를 만들지 않는다"라는 말이 있는 것처럼 이 미션에서 검증이 필요한 유틸 함수 두 개(양의 정수인지, 1000으로 나누어 떨어지는 숫자인지)를 만들었고, 이 소스코드를 테스트 코드를 통해 검증했다. 그리고 위 두 가지 메서드를 합쳐 구입 금액 클래스의 기능 테스트를 아래와 같이 네 파트로 나누어 진행했다.

import { ERROR } from '../../src/common/constants.js';
import MoneyValidator from '../../src/service/MoneyValidator.js';

describe('구매 금액 테스트', () => {
  const validateMoney = (input, expectedError) => {
    const moneyValidator = new MoneyValidator(input);
    if (expectedError) {
      expect(() => moneyValidator.validate()).toThrow(expectedError);
    } else {
      expect(() => moneyValidator.validate()).not.toThrow();
    }
  };

  test('금액이 유효한 형식이라면 성공', () => {
    validateMoney('10000');
  });

  test('금액이 1000 단위가 아니라면 실패', () => {
    validateMoney('1010', ERROR.money);
  });

  test('금액이 문자열이라면 실패', () => {
    validateMoney('abc', ERROR.numeric);
  });

  test('금액이 공백이라면 실패', () => {
    validateMoney(' ', ERROR.numeric);
  });
});

👩🏻‍🔧 트러블 슈팅

일반적인 에러는 따로 다른 글로 발행하고,
본 미션에서 마주할 수 있는 몇 개만 기술합니다.

1️⃣ 무지성 복붙 금지

로또 구입 금액을 검증하는 테스트 코드 통과를 못하고 있었다.

코드를 살펴보았더니, 다른 예외 상황인데 같은 에러 문구를 출력하고 있던 것이다..

// 수정 전
test('입력한 구입 금액이 1000 단위로 떨어지지 않으면 예외가 발생한다.', async () => {
    const invalidInput = '1010';
    Console.readLineAsync.mockResolvedValueOnce(invalidInput);

    await expect(isValidPaidAmount()).rejects.toThrow(ERROR.paid_amount); // 에러 문구
  });

  test('입력한 구입 금액이 문자열이면 예외가 발생한다.', async () => {
    const invalidInput = 'abc';
    Console.readLineAsync.mockResolvedValueOnce(invalidInput);

    await expect(isValidPaidAmount()).rejects.toThrow(ERROR.paid_amount); // 에러 문구
  });
  
// 수정 후
test('입력한 구입 금액이 1000 단위로 떨어지지 않으면 예외가 발생한다.', async () => {
    const invalidInput = '1010';
    Console.readLineAsync.mockResolvedValueOnce(invalidInput);

    await expect(isValidPaidAmount()).rejects.toThrow(ERROR.paid_amount); // 에러 문구
  });

  test('입력한 구입 금액이 문자열이면 예외가 발생한다.', async () => {
    const invalidInput = 'abc';
    Console.readLineAsync.mockResolvedValueOnce(invalidInput);

    await expect(isValidPaidAmount()).rejects.toThrow(ERROR.numeric); // 에러 문구
  });

원인은 무지성으로 복사 붙여 넣기를 한 탓이었다. 테스트 코드는 (리팩토링을 하기 전에는) 코드가 반복되는 경향이 있다 보니 아무 생각 없이 복붙을 해서 무엇이 틀린 지를 몰랐다. 분명 validator에서 예외 상황에 따라 출력되는 문구를 나누어 두었는데, 둘 다 같은 에러 메시지를 출력하게 두었으니 당연히 통과가 안되지. 이것 때문에 괜히 소스코드만 들여다보았다.

위와 같은 상황이 발생한 이후에는 사소한 실수를 방지하기 위해 나를 위한 주석을 활용했다. 습관을 잘 만들어서 시간을 아껴야 해..

validateWinningNumber() {
    this.validateNumber(); // 숫자(공백 등) 여부 판단 -> ERROR.numeric 출력
    this.validateFormat(); // 쉼표 구분 여부 판단 -> ERROR.winning_format 출력
    this.validateLength(); // 숫자 6개 판단 -> ERROR.winning_length 출력
    this.validateUnique(); // 중복 여부 판단 -> ERROR.winning_duplicate 출력
    this.validateRange(); // 1~45 여부 판단 -> ERROR.range 출력

    return this.input;
  }

2️⃣ true? false?

이번에도 또 내가 작성한 테스트 통과가 안 되는 상황이었다.

테스트 대상인 보너스 번호를 검증하는 로직 안에 사용되는 메서드들은 아래와 같이 작성해 두었었다. 이 중에서 '타겟 안에 특정 요소가 포함되어 있는지 확인하는 메서드'가 문제였다. 무엇이 문제였을까?

// 타겟 안에 특정 요소가 포함(중복)되어 있는지 확인하는 메서드
const isElementInTarget = (target, element) => target.includes(element);

// 양의 정수인지 확인하는 메서드 (음수, 소수, 공백, 특수문자, 문자열, 0으로 시작하는 숫자 불가)
const isNumeric = (input) => UTILS.positive_integer.test(input);

// 특정 범위 안에 값이 포함되었는지 확인하는 메서드
const isInRange = (input, min, max) => input >= min && input <= max;

알고 보니, 중복 여부를 검사하는 isElementInTarget 메서드의 true / false 순서를 바꾸어 두었기 때문이었다.

// 수정 전
test('보너스 번호와 당첨 번호 간의 중복 여부', () => {
    const winningNumber = '1,2,3,4,5,6';
    const uniqueBonusNumber = '7';
    const duplicateBonusNumber = '6';

    expect(isElementInTarget(winningNumber.split(','), uniqueBonusNumber)).toBe(true);
    expect(isElementInTarget(winningNumber.split(','), duplicateBonusNumber)).toBe(false);
  });

아래와 같이 isNumeric이나 isInRange 메서드와는 다르게 isElementInTarget는 중복이 있으면 false를 뱉어내야 하기 때문이다.

isElementInTarget 👉 중복된 값이 있는가? 👉 있다(true) 👉 실패
isNumeric 👉 양의 정수인가? 👉 맞다(true) 👉 통과
isInRange 👉 범위 내에 있는가? 👉 맞다(true) 👉 통과

아래와 같이 수정해 주었더니 테스트 통과가 되었다.

// 수정 후 : true & false 순서 변경
test('보너스 번호와 당첨 번호 간의 중복 여부', () => {
    const winningNumber = '1,2,3,4,5,6';
    const uniqueBonusNumber = '7';
    const duplicateBonusNumber = '6';

    expect(isElementInTarget(winningNumber.split(','), uniqueBonusNumber)).toBe(false);
    expect(isElementInTarget(winningNumber.split(','), duplicateBonusNumber)).toBe(true);
  });

이번에도 사소한 실수로 인해 에러가 났다. 하지만 이런 사소한 실수일수록 다시 반복하지 않고자 기록해 둔다.

🧹 리팩토링

1️⃣ while에서 재귀로

이번 미션부터 달라진 부분은 에러가 나면 즉시 애플리케이션이 종료되는 것이 아니라, 해당 부분부터 다시 입력받는 것이었다. 처음에는 아래와 같이 while 루프를 사용해 메서드들을 성공적으로 통과할 때까지 계속 시도하게 만들었다. 즉, 두 메서드가 에러를 발생시키지 않고 정상적으로 완료되면, break 문이 실행되어 while (true) 루프를 종료하고 start 함수가 완료되도록 했다.

// 리팩토링 전: while 루프 사용

async start() {
    while (true) {
      try {
        await this.#initGame();
        await this.#runGame();
        break;
      } catch (error) {
        printMessage(error.message);
      }
    }
  };

그러다 while문의 가독성이 떨어질 뿐만 아니라, 위와 같이 작성했을 때 ESLint의 no-constant-condition과 no-await-in-loop 조건을 위반하고 있어서 아래와 같이 재귀로 바꾸었다.

// 리팩토링 후: catch 블록 내에서 startGame 함수는 자기 자신을 다시 호출
// 재귀 호출을 통해 에러가 발생할 때마다 계속해서 자기 자신을 호출하여 게임을 초기화하고 실행하는 과정을 반복

async start() {
    const startGame = async () => {
      try {
        await this.#initGame();
        await this.#runGame();
      } catch (error) {
        printMessage(error.message);
        await startGame(); // 재귀 호출
      }
    }
    await startGame();
  };

재귀로 작성했을 때의 장점은 여러 가지가 있는데, 우선 위 코드에서는 while문보다 가독성이 명확해졌다. 그냥 단순히 보기 좋다라기보다, 재귀적으로 자신을 호출하는 함수는 '반복 작업'을 하고 있다는 것이 명시적으로 나타낼 수 있다. 더불어, 각 단계에서의 상태를 startGame 함수 호출의 스코프에 포함시킬 수 있어, 변수 상태를 전역적으로 관리하는 것보다 에러가 발생했을 때 상태를 다루기가 더 용이하겠다고 생각했다.

2️⃣ 레이어드 아키텍처 도입

지난 2주 차에 이어 이번에도 MVC 패턴을 적용해 구현하고 있었다. 그런데 어느 정도 구현을 다 하고 보니 컨트롤러에 너무 많이 역할이 부여되고, 레이어별 역할 구분이 명확하지 않은 느낌이었다. 그래서 중간에 하나의 레이어를 두어 일부 역할을 분리해도 좋지 않을까 생각했다. 그러다 이러한 고민에 어느 정도 실마리가 되어 준 것이 바로 레이어드 아키텍처(Layered Architecture)라는 것이었다. (참고: Layered Architecture @hgraca)

말이 거창해 보이지만, 쉽게 말하자면 각 계층을 애플리케이션 내에서의 특정 역할과 관심사(UI, 비즈니스 로직 수행, DB 작업 등) 별로 구분한다는 것이다. 가장 큰 특징은 명확하게 관심사를 분리할 수 있다는 장점이 있다는 것이다.

즉, 특정 계층의 구성 요소는 해당 계층에 관련된 기능만 수행하기에 높은 유지보수성과 쉬운 테스트를 할 수 있다는 장점이 있다. (참고: 계층화 아키텍처) 그래서 이 아키텍처라면 각 레이어별로 역할과 책임이 명확해, 컨트롤러의 역할이 너무 많은 것 같다는 고민을 해결할 수 있을 것 같았다.

그렇다면 어떻게 해결했느냐? 아래와 같이 컨트롤러 전에 비즈니스 로직을 수행하는 '서비스 모듈'을 하나 더 두기로 했다.

📂 컨트롤러 모듈
📄 controller.js 👉 컨트롤러 역할

📂 서비스 모듈
📄 LottoService.js 👉 비즈니스 로직 (당첨 통계, 수익률 계산 등) 수행
📄 BonusNumberValidator.js 👉 보너스 번호 유효성 검사
📄 LottoValidator.js 👉 로또 번호 유효성 검사
📄 MoneyValidator.js 👉 구입 금액 유효성 검사
📄 WinningNumberValidator.js 👉 당첨 번호 유효성 검사

서비스 레이어는 비즈니스 로직을 수행하는 것을 주 관심사로 두고 그저 Model에서 데이터를 가져와(로또 번호, 구입 금액 등), 비즈니스 로직을 수행하고(당첨 통계와 수익률 계산 등)을 수행한다. View가 화면에 데이터를 출력하거나, Controller가 View에서 가져온 결과물을 원하는 형식으로 다듬는지에 대한 내용은 알고 있지 않다.

사실 내가 적용한 Layered Architecture 외에도 어니언 아키텍처(Onion Architecture), 라자냐 아키텍처(Lasagna Architecture) 등등 여러 아키텍처가 있었지만, 이번 미션에서는 어떤 아키텍처를 사용하냐는 것은 본질이 아니었다. 기존 MVC 패턴을 사용하며 컨트롤러가 가지고 있던 필요 이상의 역할을 여러 레이어로 나누고, 각 레이어별로 관심사와 역할을 분리하는 것이었다.

이 아키텍처를 참고하며 결과적으로는 비즈니스 로직을 가장 바깥쪽에 두지 않으면서 핵심적인 비즈니스 로직은 견고하게 유지할 수 있었다. 예를 들어 보너스 번호의 개수가 1개에서 2개로 변경되어야 한다면 굳이 사용자 입출력을 변환하는 컨트롤러는 건드릴 필요가 없다. 서비스 레이어의 내부 로직만 변경하면 된다. 이에 더해, 역할 분리가 되니 각각의 유닛테스트를 짜기가 수월하기도 했다.

사실 짧은 시간 동안 아키텍처에 대해 깊게 공부하거나 적용하는 것은 무리가 있다고 생각한다. 평소에는 이런 구조적인 고민을 할 일이 없었는데, 우테코 미션 덕분에 이런 아키텍처라는 것까지 찾아보고 고민해 본 것에 의의를 둔다.

🤔 3주 차 아쉬운 점

1️⃣ 시간 분배

2주 차에 비해 3주 차 미션은 난이도가 있는 편이기도 했고, 초반부에 예외 처리 부분을 필요 이상을 꼼꼼하게 하느라 시간 분배를 잘 하지 못한 것 같다. 물론 돌아보면 이렇게 꼼꼼하게 처리하고 여러 시도를 해본 것이 결코 헛된 삽질은 아니지만, 미션 마감 시간에 닥쳐 푸시하고 테스트하느라 마지막에 소소한 코드 컨벤션을 체크하지 못한 것이 마음에 걸린다. 4주 차에는 빠른 시간 내에 돌아가는 쓰레기라도 만들어 최소 기능이라도 구현해야겠다.

2️⃣ 테스트 코드

위의 시간 분배와도 연결되는 이야기인데, 막판에 시간이 부족해서 테스트 코드 리팩토링을 제대로 못했다. 때문에 지금 보니 반복되는 코드가 많다. 게다가 '당첨 결과와 수익률 계산'에 대한 테스트 코드 하나를 작성하지 못했다. 물론 Node 환경에서 애플리케이션이 잘 돌아가고, 예외 처리를 다 해준다는 것은 눈으로 확인했지만, 테스트 코드로 비즈니스 로직을 확인했더라면 더 좋았을 것 같다. 매우 아쉬운 부분이다.

☕️ 3주 차 소감

1️⃣ 어렵고, 힘들었다.

힘들었다. 이번 미션의 난이도가 높은 것도 있었지만, 3주 차에 접어들며 체력적 정신적으로 한계에 부딪힐 때가 있었다. 그동안 잠을 줄인 탓에 체력 부채는 쌓여가는데, 점점 난이도가 높아지는 것을 느껴 조급해지기도 했다. 지난주보다 알게 된 것들이 많아지다 보니 더 잘하고 싶은 욕심 때문이었던 것 같다.

2️⃣ 위기를 기회로

하지만 이런 위기는 스스로의 절실함과 성장에 대한 욕심을 알게 된 기회이기도 했다. 더 잘하고 싶은 욕심과 절실한 마음에 잠을 줄이게 되고, 먹거나 쉴 때도 디버깅 리팩토링 생각만 했던 것 같다. 이를 통해 스스로 ‘나 개발을 이만큼 좋아하는구나, 이만큼 잘하고 싶구나’ 느꼈다.

3️⃣ 아쉬움은 성장의 기회로

소감문을 쓰며 한 주를 돌아보니, 이것 또한 과정이고 스스로 해낸 것에 큰 성취를 느낀다. 특히 지난 2주 차 때 아쉬웠던 점을 3주 차에 만회하겠다고 다짐했고, 이를 실천한 것에 뿌듯함을 느끼고 있다. 하지만 3주 차 피드백을 받으면 분명 아쉬운 점이 마구마구 생길 것이고, 나는 또 성장의 기회를 얻을 것이다. 이렇듯 앞으로 아쉬움을 느끼며 매일매일 성장하는 개발자가 되자.

'📂 Project > 우아한테크코스' 카테고리의 다른 글

[우아한테크코스] 우테코 숫자 야구 테스트 코드 분석하기 (4)	2023.11.24
[우아한테크코스] 우테코 프리코스 6기 종료 회고 (2)	2023.11.17
[우아한테크코스] 우테코 프리코스 6기 4주차 크리스마스 프로모션 미션 회고 (0)	2023.11.15
[우아한테크코스] 우테코 프리코스 6기 2주차 자동차 경주 미션 회고 (2)	2023.11.01
[우아한테크코스] 우테코 프리코스 6기 1주차 숫자 야구 미션 회고 (4)	2023.10.25