TDD, 학습에서 배운점 1

TDD가 필요해졌다

테스트 코드 첫 만남

이전 직장에 처음 입사했을 당시에, 솔루션 회사임에도 제대로 구축되어있는 솔루션이 없는 상태였다. 느리지만 한 개 고객사에 납품한 솔루션이 있었는데, 그 소스 코드를 보니 짧은 기간 작성한 이유 때문인지 컨벤션도 지켜지지 않았고, 여러 고칠 부분들과 얽혀있는 코드들의 검증이 꼭 필요한 프로젝트임을 직감했다

새로운 버전의 솔루션을 구축하게 되었고, 동료들에게 테스트 코드 도입을 먼저 얘기했다. 동료들이 테스트 코드 경험이 거의 없었고, 나 또한 실무에서 테스트 코드를 많이 작성해보지 않았기 때문에 걱정되었지만, 필요성에 대해서는 모두 공감하던 상태였기 때문에 도입을 결정했다

TDD 필요성을 느끼게 되었다

어찌저찌 순탄하지만은 않았지만, 구글에 존재하는 수많은 선배 개발자분들의 발자취를 따라서 프로젝트에 테스트 코드를 차근히 심어나갔다. 이미 존재하는 비즈니스 로직에 테스트 코드를 주입했고, 나름 범위에 따른 테스트 방식들도 정해서 규칙에 맞게 정돈된 테스트 코드를 잘 작성했다고 생각한다

하지만 어느 순간 테스트 코드를 완벽하게 사용하고 있다는 느낌을 받지 못했다. 비즈니스 로직이 완성된 후 테스트 코드를 작성하다 보니 테스트 코드가 설계 자체에 개입하지 못했고, 심지어 잘못 설계되거나 구성된 로직을 오히려 검증하는 코드가 되어버려 반쪽보다도 못한 느낌을 가지게 되었다.

이 때부터, TDD가 눈에 들어오기 시작했다. 설계 능력과 요구사항 검증을 다 해낼 수 있는 방식에 TDD가 적합해 보였고, 접근하기 매우 어려운 개념이었지만 교육을 통해서 배우게 되었고, 시행착오들에 대해서 기록하려 한다

3번째 수업전까지 피드백 내용 정리

1. Collection의 사이즈를 검증할 때는 hasSize()를 이용하자
2. @ParameterizedTest 에서 매개변수는 자동 형 변환이 가능하다
3. 매직 넘버와 매직 문자열은 상수화해서 사용한다
4. 변수명은 축약하지 않는다
5. getter, setter 사용을 최소화한다
6. 변수명을 작성할 때 의미를 생각하자(validate의 경우 check/validate/verify)
7. 랜덤 값 같이 테스트하기 어려운 경우 상위 객체로 책임을 옮기자
8. getter 대신에 객체에게 질문을 하는 메시지 전달 방식을 사용하자
9. indent는 1번만 들어가도록 작성하자
10. 인스턴스 변수는 2개에서 최대 3개만 가지도록 하자
11. 원시값들도 클래스로 감싸보자
12. 일급 컬렉션을 쓰자
13. 객체지향 생활 체조 원칙을 생각하자

객체지향 생활 체조 원칙

강제성을 가지기 보다는 규칙을 지키려고 노력하다보면 좋은 코드가 될 확률이 높다고 생각하자

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