Clean Code ~Ch.9

단위 테스트에 대해 저자의 관점이 드러난 챕터다. 내가 제일 경험이 적은 파트기도 해서 쓸 내용이 많이 생각나진 않았다. 그래서 최대한 책의 핵심 내용을 찾아보고자 문장을 선택했다.

Chapter.9

그러고 나서는 테스트 코드를 버렸다.

나를 비롯한 많은 학생들이 많이 하는 실수(?)라고 생각한다. 프로젝트를 끝내는 것에 집중해 테스트 코드를 소홀히 한다.

실제로 GDSC 활동을 하면서 Spring을 많이 썼다. 하지만 테스트 코드를 관리하진 않았다. 테스트 코드를 작성한다고 해도 시간이 흐르면, 결국 통과만 하는 테스트로 전락해버리고 무의미하게 변했다.

하지만 나는 그래도 작성이라도 조금 해보았지만 test 폴더가 아예 빈 팀도 많았다. 우리 팀에서도 테스트 코드를 작성하지 않아 내가 작성한 경험도 있다.

말이 조금 샜지만 이 문장을 읽고 훌륭한 개발자도 나와 같은 경험을 하고 있었다는 것이 그래도 안심이 되는 부분이었다. (물론 테스트가 매우 중요한 것이 널리 알려진 시대에 나는 개발을 하는 것이지만…)

일회용 테스트 코드와 자동화된 단위 테스트 슈트, 둘 사이는 간극이 아주 크다.

아마 프로덕션 수준의 코드는 자동화된 단위 테스트 슈트가 필요하다는 것을 말하는 것 같다. 일회용 테스트 코드로는 큰 수준의 프로젝트를 유지할 수 없다.

그리고 조금 더 생각을 해보면, 자동화에 초점을 둘수도 있을 것 같다. DevOps가 유행하는 현재 사람들은 CI/CD를 많이 공부하고 있다. 테스트를 자동화할 수 있다면 테스트에 많은 시간을 할애하지 않아도 된다. 우리는 오직 테스트 코드, 소스 코드에만 집중할 수 있다.

이런 것도 조금 집중을 할 수 있을듯 하다.

결함 수가 많아지면 개발자는 변경을 주저한다. 그러면 코드는 망가지기 시작한다. > 테스트 코드는 실제 코드 못지 않게 중요하다. > 버그가 숨어들까 두렵기 때문이다.

최근 하늘 고래의 사용 서버가 많아지면서 잔버그가 많아지고 있다. 이걸 고쳐야하는 것을 알고 있지만 시간이 없다는 핑계로 차일피일 미루고 있다.

그리고 시간이 누적될수록 고쳐야할 버그가 많아지고… 변경을 주저하고 있다…(?)

물론 이 문장이 이것과 다른 것 알고 있다. 단지, 문장 자체만 놓고 보았을 때 그냥 뜨금해서 골랐다..

농담조로 서술했지만 테스트 코드의 필요성을 느낀 부분이었다. 내가 불안을 느끼는 큰 이유도 결국 수정하다가 다른 버그가 터지면 어떡하지라는 점도 있다.

위에서 서술한 잔버그 중 하나는 음악이 재생 중간에 한번씩 끊기는 것이다. 원래는 이러지 않았다. 봇을 업그레이드하고 나서 간헐적으로 발생하는 버그다. 사용 서버가 늘어나서 생긴 버그라고 지금은 이야기를 하고 있지만 버그 발생 시기가 업데이트 이후라 정확한 이유는 확실히 모른다. 이런 상황에서 버그 수정을 위한 업데이트를 진행하였다가 다른 버그가 생기면 어떡하지라는 마음에 더 손을 댈 수 없는 것도 있는듯하다.

하지만 테스트코드를 진작 만들어뒀다면 이런 고민없이 진행할 수 있을 것이었다. 물론 디스코드 봇이라는 한계점이 존재해 완벽한 테스트 코드를 작성할 수 없겠지만 그래도 할 수 있는 최대한을 만들어두면 좋았지 않을까 하는 아쉬움이 남는다.

숙련된 개발자라면 자기 코드를 좀 더 간결하고 표현력이 풍부한 코드로 리팩토링해야 마땅하다.

클린코드와 리팩토링은 바늘과 실 관계인 듯 하다. 클린코드를 작성하기위해 리팩토링을 해야하고 리팩토링은 결국 클린코드를 만든다. 닭이 먼저냐, 달걀이 먼저냐 느낌이다.

앞에 장에서 이 책은 작명과 분할을 통해 코드를 최대한 표현적으로 만드는 법을 설명했다. 왜 그렇게 (거의 광적으로) 집착하는지 알 것 같다.

책의 절반을 읽어가는 시점에 드는 생각은 생각보다 클린코드를 작성하기 위한 방법은 간단한 것 같다. 이 문장이 그 핵심이 아닐까 싶다.

간결하고 표현력이 풍부하게 작성하라.

이 방법을 현실적으로 구현해내기 위한 방법들을 이 책은 소개하고 있다.

테스트 환경은 자원이 제한적일 가능성이 낮다.

환경에 대해 생각해볼 문장이었다. 여기서는 테스트 환경이라고 적혀있지만 우리는 개발을 하며 많은 환경을 마주한다. 크게 2개로 나누어서 보아도 실제 개발을 진행하는 로컬, 코드가 돌아갈 서버로 나뉜다. 로컬에서 돌아가는 코드가 서버에서 돌아가지 않는 일은 허다하게 봤다. 최근에는 Docker의 등장으로 많이 해소가 되었다고 생각하지만, 그래도 학생의 입장에서는 주위에서 심심치 않게 들린다.

비록 이 챕터가 테스트에 관한 내용이고 이 문장은 테스트 환경을 고려하라는 내용이지만, 나는 자원이 제한적이다는 것에 초점을 두기보다는 환경이 다르다는 것에 집중해보았다. 하늘 고래도 지금 집에 있는 서버에서 돌아간다. 당연히 서버 컴퓨터는 내 노트북보다는 성능이 훨씬 낮다.

봇 개발 초기에 개발을 끝낸 뒤, 로컬에서 실제 테스트를 진행하는데 음악이 자꾸 끊겨서 재생됐다. 실사용에 문제가 있을 정도로 끊김이 심해 꽤 많이 고전했다. 오랜 검색과 테스트끝에 라이브러리에서 그 해결법을 찾을 수 있었다.

Linux에 최적화되어 있고 그 외의 OS에서는 원할히 동작하지 않을 수 있다.

이 말을 믿고 서버에 업로드를 해서 테스트를 하니 음악이 원할히 재생되었다. 정말 신기한 경험이었다. 성능은 무조건 떨어지는데 최적화의 차이로 이정도로 차이가 날 수 있다는 것을 알았다.

개발을 할 땐 꼭 환경을 고려해야하고 실제로 동작할 환경에 많은 포커스를 둬야하는 것도 알았던 경험이 떠올라 문장을 선택했다.

assert 문 개수는 최대한 줄여야 좋다는 생각이다. > 테스트 함수 하나는 개념 하나만 테스트하라

테스트를 하는 함수도 결국엔 함수다. 함수는 최대한 적은 역할을 맡는 것이 좋고 이것은 테스트 코드라도 별반 다르지 않다는 내용이다.

처음 테스트 코드를 작성할 때 User와 관련된 테스트 코드를 작성했다. 어디서 주어들은 것은 있엇 많은 예외 상황들을 나름 가정해보았고 거기에 대응하는 코드를 작성해보았다. (그때는, given when then도 몰랐다.)

처음에는 테스트가 정상적으로 통과했지만 어느 순간 통과하지 않았고 그 부분을 알기 위해 결국 하나씩 함수로 분리를 했던 경험이 있다.

이 경험이 떠오르는 문장이라 선택을 했다.