[우아한테크코스] 레벨1 되돌아보기(1) - 단위테스트/코드 품질

 

🍋 단위테스트

 

1. 내가 단위 테스트를 작성하는 이유는 무엇인가?

 

나는 레벨1의 후반까지 계속 단위 테스트를 작성하면서도, '단위 테스트, 그거 꼭 작성해야해?' 라는 의문을 계속 가지고 갔었다. 남들도 하니까, 리뷰어가 테스트가 부족하다하니까, 관성적으로 작성했던 적도 많다. 하지만 최근으로 올수록 복잡해진 미션을 수행하면서 단위 테스트를 작성해야 하는 이유를 어렴풋이 느낄 수 있게 되었다.

 

내 머리는 내가 생각하는 것보다 멍청하기 때문이다.

 

머리로 생각만 하는 것보다 직접 쓰면서 확인하는 것이 사고의 오류를 잡아내기 쉽다. 일일이 써서 확인하는 일은, 특히 테스트 해야 할 복잡한 경우의 수가 많을수록 강한 위력을 발휘했다. 블랙잭 미션을 하면서 승패를 가르는 결과를 판단할 때 많은 경우의 수가 필요했다. 머리로는 완벽한 로직을 짰다고 생각했지만, 각각의 경우를 테스트를 돌려보면 깨질때가 있었다. 

플레이어가 버스트인 경우
    딜러가 버스트인 경우
    딜러는 블랙잭인 경우
    딜러는 일반 점수인 경우
플레이어가 블랙잭인 경우
    딜러가 버스트인 경우
    딜러는 블랙잭인 경우
    딜러는 일반 점수인 경우
플레이어가 일반 점수인 경우
    딜러가 버스트인 경우
    딜러는 블랙잭인 경우
    딜러는 일반 점수인 경우

 

테스트 코드를 돌렸을 때 나오는 초록불이 내 머리보다 더 신뢰성이 있음을 알았기에, 나는 단위 테스트를 작성하기로 했다.

 

2. 내가 작성한 좋은 단위 테스트는 어떠한 부분에서 좋은 단위 테스트라 느꼈는가?

 

특정 기능에 대하여 모든 경우의 수에 대해 빠뜨리지 않고 테스트 코드를 짰을때 좋은 단위 테스트라고 느꼈다. '남들도 하니까, 리뷰어가 테스트가 부족하다하니까 짜는 눈속임용 테스트 코드'는 야매를 부리기 마련이다. 가령 테스트 커버리지가 적당히 통과될 정도만 짜고, 몇몇 테스트 케이스를 빼먹는다던지 말이다. 여기에서 벗어나, 내가 진짜로 내가 생각한게 맞는지 검증의 끝장을 보고 싶어서 짠 테스트 코드는 이 코드가 정말 필요한 테스트 코드임을 내 자신이 필요성을 느껴서 짠것이므로 좋은 단위 테스트라고 생각한다. 경험상 그런 코드일 수록 코드를 작성하는데 애정도 더 묻어나고, 나중에 봐도 알아볼수 있는 가독성 좋은 테스트 코드가 짜여진다. 결론은 테스트가 존재하는 이유를 나 자신이 납득할 수 있다면 좋은 단위 테스트가 짜여질 수 밖에 없다는 소리다.

 

3. 위와 같은 좋은 단위 테스트를 작성하기 위해 어떠한 시도를 해볼 수 있는가?

 

하나의 테스트 파일 안에서 여러 경우에 대한 테스트를 작성하다보면, 가독성이 구려질 때가 존재한다. 그렇다보면 테스트 코드를 짜면서 지치기도 하고, 내가 무엇을 빼먹었는지 놓치기도 쉽다. 나는 블랙잭 미션의 리뷰어로부터 DCI 패턴을 이용해 중첩된 테스트를 작성해보는 것이 어떻겠냐는 이야기를 들었고, 바로 적용해보았다.

 

DCI(Describe, Context, It) 패턴은 Given - When - Then 패턴처럼, 테스트 코드를 짤 때 적용해볼 수 있는 패턴 중 하나이다. DCI 패턴을 이용해 계층적으로 테스트 코드를 짜면 조건과 결과가 구분되도록 구조화하여 테스트 코드를 상세하게 구현할 수 있다는 장점이 있다. 이를 통해 코드를 작성하는 나 뿐만 아니라, 코드를 읽는 사람도 내용을 빨리 파악할 수 있게 된다. 무엇보다도 빠뜨린 테스트를 찾기 쉬워진다는게 내가 제일 크게 생각하는 장점이다. (참고)

 

 

 

🍋 코드 품질

 

1. 코드 품질이 중요한 이유 중 가장 와닿는 이유는 무엇인가?

 

코드 품질이 중요한 이유 중에서, 나는 읽기 쉽기 때문이라는 이유가 가장 와닿는다. 내 코드가 잘났든 못났든 일단 읽기 쉬워야 남들에게 내 코드에 대한 조언을 구하거나 리뷰를 받기도 편한 것 같다. 레벨1을 하면서 몇번 다른 크루들의 코드를 리뷰해보기도 했는데, 경험상 읽기 쉬워야 코드에 대한 호기심이 올라가고, 코드를 더 읽고싶다는 생각이 들었고, 더 깊이 있는 리뷰를 남길 수 있던 것 같다. 

 

2. 위 이유를 만족하기 위한 코드를 작성하기 위해 어떠한 노력을 해봤는가? 혹은 할 예정인가?

 

객체지향 생활체조 원칙을 준수하려고 노력했다. 후반으로 갈수록 미션이 복잡해지다보니 배째 모드로 간 것 같기도 한데, 다음 레벨부턴 다시 초심으로 돌아가야겠다고 생각하는 중이다.

규칙 1: 한 메서드에 오직 한 단계의 들여쓰기(indent)만 한다.
규칙 2: else 예약어를 쓰지 않는다.
규칙 3: 모든 원시값과 문자열을 포장한다.
규칙 4: 한 줄에 점을 하나만 찍는다.
규칙 5: 줄여쓰지 않는다(축약 금지).
규칙 6: 모든 엔티티를 작게 유지한다.
규칙 7: 3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.
규칙 8: 일급 콜렉션을 쓴다.
규칙 9: 게터/세터/프로퍼티를 쓰지 않는다.

 

또, 메서드명과 변수명을 앞으로는 더욱 신중하게 지을 예정이다. 이젠 Chat gpt라는게 존재한다는 것도 알았으니, 종종 Chat gpt에게 조언도 구해볼 예정이다.

 

3. 코드 품질을 높은 코드를 작성하는 프로그래머가 훌륭한 프로그래머인가? 그렇게 생각한 이유는 무엇인가?

 

당연히 훌륭한 프로그래머라고 생각한다. 내가 그런 프로그래머가 되고 싶기 때문이다. 그런데 왜 그런 프로그래머가 되고 싶냐고 물어본다면, 단순히 '내가 이해하는 코드' 에서 벗어나, '남들도 이해하는 코드' 를 짜고 싶기 때문이다. 이것은 내가 악필을 탈출하고 싶은 이유와 맥락이 통한다. (나는 아직도 고딩시절 수학학원 선생님이 이름이 안써있던 내 문제집을 다른 남학생 문제집이라고 착각하고, 그 남학생도 자기 문제집이라 착각했던 것이 상당히 큰 충격이다.) 내가 글씨를 열심히 써도, 남들이 내 글씨를 이해 못하면 나는 다시 내 입으로 내가 무엇에 대해 썼는지를 설명해주어야 한다. 코드도 마찬가지일 것이다. 내가 입을 터는 힘을 아끼려면 품질이 높은 코드를 짜는 것이 좋을 것이다. 그렇게 비축해둔 힘은 더 중요한 부분을 설명할 때 사용하고 싶다.