숫자 야구 게임 구현
미션 리팩터링 하기
TDD 첫 발걸음
TDD 방법론을 공부 하며 직접 적용 한 적은 처음이다. 그 동안 구현한 기능에 대한 단위 테스트만 잘 작성 하더라도 리팩터링 할 때 앞을 보고 걸을 수 있으리라 생각 해왔기 때문이다.
재성님의 피드백 영상을 본 뒤 한 1주일은 머릿속에 TDD 사이클을 어떻게 체득 할 것인가, 어떻게 수정 해 볼 수 있을까란 생각이 온통 지배했었다. 그 당시 지하철로 출 퇴근 하면서 영상을 봤었는데, 내가 지금 당장 노트북을 켤 수 있다면 뭐든지 할 수 있을 것만 같았다. 겉 보기에 너무 쉬웠다.
그렇게 첫 TDD를 적용 하여 유저가 입력한 숫자를 관리 해 줄 Ball VO 객체에 대한 테스트 케이스를 구현 하고 서비스 로직을 구현했다. 생각 했던 사이클은 온데간데 없고 하얀 백지속의 머리와 키보드로 단어를 적었다 지웠다 반복하는 나 만이 남았다.
피드백 영상의 악영향
피드백 영상 시작 부분에서 TDD가 익숙하지 않다면 충분한 설계를 하고 진행 하라고 안내 해준다. 마크다운으로 태스크를 하나 둘씩 적어 나갔고 완벽한 시나리오를 만들었다.
하지만, 테스트 케이스를 작성 할 때 마다 피드백 영상과 사뭇 다른게 없었다. 오로지 코드 클로닝 하는 기분이 들어 커밋을 남긴 채 노트북을 덮고 1주일 뒤 다시 시작 하리라 기약했다.
서비스 코드 왕따 시키기
테스트 코드를 중점으로 코드 작성을 다시 시작했다. 처음엔 여전히 버벅였지만 테스트 코드를 먼저 작성한 뒤 컴파일 에러를 해결 하고 실패 시킨 뒤 성공 하여 리팩터링을 진행 했다. 하나 둘씩 문제가 풀리니까 재밌었다.
노트에 어떻게 설계 하면 좋을지, 테스트를 위한 Fixture는 어떻게 구성 하면 좋을지 미리 다 계획 하고 진행 했다. 처음 작성 했던 마크다운의 태스크는 이미 버저닝이 되어 업뎃 안한 쓰레기가 된지 오래였다.
유효성 검증, 비즈니스 로직의 경계 지점 검증, 에러 케이스 검증을 무아지경으로 하다보니 어느새 서비스 코드는 안중에도 없고 테스트만 하고 있는 나를 발견했다. 그 동안 내가 강조하고, 내가 추구하던 클린 코드는 사라진지 오래다. 오로지 테스트 또 테스트 그리고 초록색만이 남았다.
그래서 무엇을 배웠는가
콘솔로 하는 토이 프로젝트를 이렇게 열심히 해본 적 있던가? 노트를 펼쳐 내 생각을 그려가며 코드를 작성 했던 때가 있던가?
돌아 봤을 때 굉장히 많은 것을 배웠다. 이를테면 자바의 문법 중 Stream을 이번 기회에 정말 많이 다뤘던 것 같다. 사실 파이썬의 Map 과 같은 개념으로 사용 하다보면 IDE가 아슬 아슬 줄타기 하는 나를 붙잡아주었다.
또한, 객체를 설계하는 객체 위주의 관점(클래스 위주가 아니었다는 점), 테스트 코드에 익숙해졌다는 것 그리고 진짜 자바를 배운 것 같다.
무엇을 개선 할 것인가
서비스 코드를 구성 하면서 좋은 코드를 작성 하는 습관을 많이 놓쳤다. 예를 들어, 상수 처리, 객체에게 메시지 보내기 또는 추상적인 레벨에서 구현 코드의 깜짝 등장 아니면 패키지 구조? 스스로 개선 하고 싶은점이 많다고 느꼈다.
테스트코드의 중복이 너무 많았다. 아무래도 하나의 기능에 대한 다양한 테스트 케이스를 모두 테스트 하다보니, 중복으로 호출 하는 경우가 많았는데 적절한 Fixture 사용이나 필요 없는 검증이 포함 되지 않았는지 판단 하는 것이 필요하다고 느꼈다.
테스트 브랜치 커버리지 개선이 필요하다. 못 해도 90% 이상은 채웠어야 했었는데, VO 객체에 대한 동등성 검증이 대부분 안 이루어져서 커버리지가 많이 낮아졌다.
I/O Handler, Application 코드의 부재도 크다. 사실 비즈니스 로직만 구현 하면 될 것이라고 생각하고 작성 하긴 했지만 TDD 방법으로 개발 하다보면 MVC 구조에서 뷰와 컨트롤러는 제외하고 모델에 대한 도메인 로직을 검증 했는데 모든 힘을 다 쏟았다.
Last updated