TDD 시작하기 - 1

Posted on Edited on Disqus:

연재



TDD를 시작했다는 건 아니고, TDD 공부를 시작했다는 말이다.

스터디 조직

TDD 참관 이후 뭔가 해야겠다 마음만 먹고 있다가, 같이 일하는 주니어 친구가 TDD에 관심있어 한 것을 눈여겨 보다가, 마침 사내 UX 스터디도 끝나는 분위기라 사내 스터디를 조직해봤다. 교재는 그 친구가 관심있어 했고, 나도 한번 맹대표님 스터디 S66 참여로 어설프게 읽어본 적 있는 테스트 주도 개발로 배우는 객체 지향 설계와 실천으로 정했다.

테스트 주도 개발로 배우는 객체 지향 설계와 실천 이미지

같이 참여한 또 다른 열정적인 친구는 이 책으로 동시에 다른 스터디를 조직해서 공부하는 열정을 보이기도 했다. 그 멤버 구인 글에 박성철님은

스터디를 응원합니다. 그런데 교재가 TDD를 공부하기에 좋은 책인지 의문입니다. 저기서 말하는 TDD는 흔히 말하는 TDD가 아니라서요.

라고 코멘트를 다셨는데, 왜 흔히 말하는 TDD가 아닌지는 아직 말씀을 안 하셔서 모르겠다. ‘흔히 말하는 TDD’가 뭔지…사람들이 흔히 말하는 TDD는 Mock과 프레임웍이 덕지덕지 엉킨 코드가 아니던가!(농담이다. 넘어가자)

어쨌든 이 책이 보여주는 특징 중에서 아래 두가지 때문일까 생각만 해봤다.

  1. 저자들은 단위테스트 뿐 아니라 정기 회의, CI, CD, 인수테스트 등 촘촘한 중첩된 피드백 계층을 만드는 것을 중요하게 생각한다는 점(책에서는 기술적인 내용을 중심으로 풀고 있지만)
  2. Mock을 적극 사용한다는 점(처음에 책을 쓰기 시작한 이유는 Mock을 제대로 쓰는 법을 알려주고 싶었기 때문이라고 한다)

이유야 어찌됐든 이 책은 TDD를 시작하는 사람들에게 적당한 책은 아니다. 서문에도 ‘지식이 풍부한’ 독자를 대상으로 한다고 나와있다. 제목을 다시 보자.

테스트 주도 개발로 배우는 객체 지향 설계와 실천

원제는 Growing Object-Oriented Software, Guided by Tests. 테스트의 안내를 받으며 진화하는 OO 소프트웨어라는 의미. TDD는 기본으로 깔고 설계를 논하는 책이다. 무려 8장까지 저자들이 생각하는 좋은 설계와 관점을 이야기 한다. 목차는

1부 서론

  • 1장 테스트 주도 개발의 핵심은 무엇인가?
  • 2장 객체를 활용한 테스트 주도 개발
  • 3장 도구 소개

2부 테스트 주도 개발 과정

  • 4장 테스트 주도 주기 시작
  • 5장 테스트 주도 개발 주기의 유지
  • 6장 객체 지향 스타일
  • 7장 객체 지향 설계의 달성
  • 8장 서드 파티 코드를 기반으로 한 개발

요즘 TDD를 많이 전파하시는 분들로부터 ‘나는 한때 mockist였지만 이제는 거의 mock을 사용하지 않는다’는 고백을 종종 보게 되는데, 나도 한때는 mockist 좀 되어 볼 요량으로 계속 공부 해보기로 한다. mockist에 관한 이야기는 다음 포스트에 더 하기로.

첫 시간은 무얼 해야 하는가

의외로 10명이나 되는 많은 분들이 관심을 보였는데, 그러다보니 TDD에 대한 다양한 관점과 다양한 이해도가 섞여 바로 진도를 나가는 게 맞는지 의문이 들었다. 우선 매주 월요일 한시간 모여 진행하기로 했는데, 역시나 진행해보니 확실히 시간이 부족했다. 난 두시간은 했으면 했지만 다들 너무 바쁘기도 했고, 퇴근 시간에 하려 해도 자율 출퇴근이라 퇴근하는 시간이 모두 달랐고.

첫 주제로는 마침 OKKYCON: 2018 발표 영상이 올라온 지 얼마 안 되었을 때라, 이것부터 보고 같이 이야기 하기로 했다. 영상은 모두가 보지만, 한사람씩 하나의 영상을 맡아서 요점 정리하기로 했다. 총 7개 영상인데, 그 중에 5개 영상을 선정했고 다음주에 모였다.

한 10분 정도 요약한 내용을 이야기하고 정리하면 되겠다 예상했지만, 다들 열심히 준비를 하셔서 3개의 주제에 대해서 이야기 하는데 한시간이 훌쩍 넘어갔다. 결국 다음 시간까지 이어졌다.

  1. 정진욱님 - 테스트하기 쉬운 코드로 개발하기
  1. 박재성님 - 의식적인 연습으로 TDD, 리팩토링 연습하기
  1. 이혜승님 - 테알못 신입은 어떻게 테스트를 시작했을까?
  1. 양완수님 - 테스트를 돌보기 위한 매우 간단한 실천 방법들, 그리고 효과
  1. 이규원님 - 당신들의 TDD가 실패하는 이유

TDD 맛보기

세번째 시간에 모이기 전까지는 백명석님의 클린 코더스 강의 중 9. TDD 4 - primefactors 실습해오기로 했다. 이건 숙제 검사까지는 안 하고, 당일 모여서는 단체 실습을 하기로 했다.

Java를 주 언어로 쓰는 사람이 많고 모두 Java 코드는 읽을 수 있으므로 언어는 Java로 선택. 한명씩 돌아가며 다음 단계를 어떻게 진행할 지 이야기하기.

실습 주제로는 한시간 안에 해치울 수 있을 정도로 간단한 것을 원했는데, 로또 번호 추첨기, FizzBuzz, 가위바위보 같은 걸 생각해봤었다. 이전 회사에서는 가위바위보 게임을 이런 방식으로 만들어 본 경험이 있었는데, 이런 쉬운 주제도 다들 생각하는 방향이 다르면 한시간도 충분치 않았던 기억이 있었다. 하지만 간단하면서도 여러 객체의 관계를 고려할 만한 주제가 좋을 것 같아서 급하게 기획서를 만들었다. 대충 이렇다.

- 우리는 사용자를 부추겨 포인트를 탕진하게 만드는 것이 목표입니다
- 한 세트당 번호 6개를 받고 100원씩 포인트를 차감합니다
- 사용자는 원하는 세트 수를 고를 수 있습니다
- 당첨 확률은 관심 없으니 그냥 랜덤하게 숫자만 6개씩 나와도 됩니다
- 한 시간 안에 충분히 개발 가능하다고 이미 CEO 보고 들어갔습니다
- 오류가 발견되면 당신은 해고입니다

이를 토대로 기본 뼈대를 만들어 공유했다. Java로 10년 만에 코딩한 것 같은데, TDD로 기본 예제를 만들어 나간 과정이 재밌었다 - 설계는 엉망이었지만. 당일에는 한시간 밖에 시간이 없으니 User와 Point의 인터페이스는 미리 정의했고, Lotto 서비스의 구현에 집중하려고 했다.

구현은 아래 과정을 통해 진행하려고 했다.

  • 요구사항 검토
  • 명세 작성
  • 설계
  • 실습 준비
  • TDD
  • 완성 + 박수!

명세를 만들 때는 아래의 규칙으로 작성하기로 했..으나 그게 참 쉽지가 않다. 총체적 혼란이었다.

누가 / 무엇을 위해 / 어떤 행동을 한다

참고 :

사실 예제를 리허설하며, 서둘러 코딩부터 진행하면 빠질 수 있는 함정을 하나 준비하기도 했는데, 주원님이 코딩을 멈추고 명세부터 확실히 하고 가자고 하셔서 미리 준비한 허술한 꼬임은 실패했다. 어쨌든 좋은 방향이라서 좋았다. 여기서 이야기를 나누고 기능을 확정하는데까지 시간을 거의 다 써서 코딩 시간에는 한사람씩 겨우 돌아가는 수준으로밖에 진행하지 못했다. 결국 남은 건 각자 코딩해서 PR 올리기로 했고, 서로 코드 리뷰를 했다.

이렇게 DAY 3까지 완료했고, 교재를 보기 시작했다.

2편에서 계속.