느낀점 private, field, testcase, 게임option

프라이베이트, 필드

constructor도 뭔지 잘 모르겠다 생각하던 차에

field의 개념이 들어와서 새로 학습하고,

#private, static public의 개념을 새로 알게 되었다

private를 외부에서는 이용할 수 없기 때문에

인풋을 Lotto.js가 받아 결과를 만들기 위한 로직은 오로지 Lotto 클래스에서 해결해야 한다는 것을 설계할 때 어렴풋이 짐작을 했었다

하지만 실제로 입력을 받아 출력을 하기 위한 코드를 짜려고 하니 너무 어려웠다.

---

테스트케이스

testcase를 만들면서 다른 사람들이 만들어 놓은 테스트 케이스를 많이 확인했는데

작동을 시키고 테스트에 통과되어도 제대로 하고 있는 것인지 잘 모르겠다.

이 과정을 진행하는 의미를 알기 위해서는 따로 찾아서 공부를 해야할 것 같지만

솔직하게 구현하고 리팩토링 하는데만해도 시간이 모자란다...

 

문제가 생기고 나서야 비로소 테스트케이스를 왜 하는지 알게 되었다.

잘 작성된 테스트케이스는 어떠한 문제가 언제 어디서 생겼는지 바로 확인할 수 있게 도와준다.

그만큼 테스트케이스를 의미있게 작성하지 못 할수록 오류를 놓칠 가능성이 높아진다는 의미이다.

역시 문제가 생기고 힘들어 봐야 왜 이런 것들이 다 필요한지 알게 되는듯 하다.

---

게임 옵션

게임 규칙을 이루는 숫자들을 option으로 만들어 두었다.

const OPTION = {     PRICE: 1000,     LENGTH: 6,     LOW_NUMBER: 1,     HIGH_NUMBER: 45, };

로또 옵션 복권 한 장당 가격 복권 숫자의 길이 가장 작은 로또 숫자 가장 높은 로또 숫자 각각 무엇을 의미하는지 쉽게 알 수 있도록 이름을 지었다. 옵션을 변경하면 바로 게임에 적용이 되기 때문에 로또 규칙을 손쉽게 바꿀 수 있다.

아쉬운 점 옵션을 테스트케이스에서도 바로 적용시킬 수 있도록  ERROR안의 문구를 수정하려 했지만 throw new Error("[ERROR] 중복된 숫자가 포함되어 있으면 안됩니다."); 에러 안에서는 백틱(`${}`)이 적용되지 않고 그대로 출력되는 문제가 있어서 실제 오류가 발생했을 경우에는 옵션의 내용이 OPTION의 값이 변경된 대로 출력시킬 수 없다. 또한 테스트 케이스를 수정해야 기능 테스트를 올바르게 실행할 수 있다. 따라서 옵션별로 테스트케이스를 만들지 않는 한 올바른 테스트가 이루어지고 있는지 확인하기 어렵다. const lottos = [     [1, 2, 8, 12, 14, 37],     [1, 2, 3, 4, 5, 6], ];

 

3등이 출력이 안되는 버그 발견

함수를 분리하다가 보너스 번호까지 완전 떼어버려서 등수를 구하는 로직에 문제가 생겼지만 미처 발견을 못하고 있다가 다른 분 덕분에 3등, 2등이 모두 2등으로 출력되는 버그를 찾게 되었다.

다행히도 함수를 잘게 나누어 놓았기 때문에 해당 함수에서만 기능을 수정하면 되어서 문제가 커지지 않았다.

문제의 원인은 테스트 케이스를 만들 때 3등 케이스를 만들지 않았기 때문이었다.