켄트 벡 의 ‘테스트 주도 개발’ 책 예제를 팀 스터디로 같이 페어프로그래밍을 하다가 1부까지만 하고 다른 책으로 넘어가게 되었다. 예전에 읽을 때도 이 책의 2부는 건너뛰고 해보지 않아서 궁금함을 안고 예제를 구현해보니 괜찮아서 영업하러 짧게 쓴다. ㅋㅋ
내가 예전에 2부를 건너뛰었던 이유
켄트 벡은 2부를 시작하며 이렇게 이야기하는데:
2부를 끝내고 나면 파이썬에 대해 개론적으로 이해하고, 자신만의 테스팅 프레임워크를 작성할 수 있게 될 것이며, 좀더 교묘한 TDD의 예를 알게 될 것이다. 그야말로 일석삼조다
일석 삼조라는 말에 별로 동의가 안됐던 것으로 기억한다.
1부는 Java로 예제를 제공한다. 근데 2부에서 갑자기 예제가 파이썬이 될거라 하니 언어를 스위칭하기가 번거롭다고 생각했다. 파이썬을 모르지 않았지만 내 주 언어인 Java로 된게 아니면 기술 자료를 읽을 생각이 없었다.
잘 짜여진 junit이 있는데 자신만의 테스팅 프레임워크를 짤 줄 아는게 뭐가 좋나 라는 생각도 했고
1부 예시를 통해 예시는 충분히 봤다는 오만한 생각을 가졌었다.
이번엔 왜 했나?
언어가 뭔 상관.. TDD를 내가 더 익히는게 중요하다. 그리고 켄트 벡도 파이썬이 주 언어는 아님에도 언어를 바꾼 이유가 있겠지 싶었다.
매일같이 쓰는 xunit을 클론코딩 해본다고 생각하면 충분히 의미가 있다
1부를 두번씩 따라해보고도 여전히 TDD를 제대로 체화하는건 어렵다 .. 는 생각을 했다.
해보고 나서 생각해봄: xunit을 구현해봤을 때 좋은 점
테스팅 프레임워크를 너무 당연하게 사용해왔는데, 사용자가 아닌 생산자 입장에서 해보면서 ‘아 사실 이런 기능이 있어서 내가 잘 쓰고 있구나’ 를 상기하게 되었다.
TDD를 하기 위해 갖춰진 테스트 프레임워크가 필수 전제조건은 아니라는 것을 상기시켜준다. xunit을 구현하는 예제니까 당연히 xunit없이 출발하는 모습을 볼 수 있다.
테스팅 프레임워크를 직접 만들어 쓸 일이 없다고 생각했지만, 의외로 쓸 수 있다. 또는 아이디어를 차용해서 전체 소프트웨어를 테스팅하는 도구를 만드는 데에 유용하게 쓸 수도 있다.
TDD에서 숨쉬듯 사용해야하는 그 것을 직접 만들어본다는 의미도 있다
중요했던 학습 포인트들
(사실은 1부에서도 나왔던 이야기의 연속인 부분들도 있지만 적어본다)
23장 195-196p.를 구현할 때 메서드마다 매번 TestResult 객체를 만들어내야한다는걸 인지하게 되고 나라면 바로 추상화부터 시작했을거라 생각했다. 그러나 일단 하던 작업을 끝까지 가보고나서 리팩토링하고 중복을 없앤다. 이 부분에선 일부러 구조적으로 중복을 만들어냈다는 생각을 했다. 더욱 추상화의 이유와 어떻게 추상화해야하는지가 잘 드러나고 실수하지 않도록.
중요한 문제를 바로 처리하지 않고 할일 목록에 적어둔다. → 지금 하는 일을 크게 만들지 않고 잘게 잘게 쪼개는 기술
처음부터 상세한 구현을 생각해서 투두리스트를 펼쳐놓지 않는다. 러프하게 필요한 투두들을 적어놓고 시작하며, 구현하다보니 필요한 게 생기면 그 때 투두를 추가한다.
testSuite 구현하면서 컴포지트 패턴이 유용하게 쓰이는 훌륭한 예제라고 생각했다. 테스트 하나도 run 할수있어야하고 테스트 suite도 똑같은 방식으로 run할 수 있어야 함 → 컴포지트.
2부 따라하면서 살짝 잘 안됐던 부분. 몰랐던 개념들
→ 예제 따라해볼 사람은 참고해볼만 할수도….
18장.
예제가 python3 이전버전을 기준으로 작성되어있어서 syntax 에러가 발생한다: SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)?
1test =WasRun('testMethod')
2print(test.wasRun) # should be None
3test.testMethod()
4print(test.wasRun)
python 실행을 어떻게 하는지에 대한 가이드는 없다. xxx.py 파일 하나 만들어놓고 한 파일에서 클래스 계속 만들면서 해당 파일을 python xxx.py 명령어로 실행시킴.
19, 20장.
print구문을 다 없애고 assert로만 테스트를 하다보니. assertion error가 발생하지 않는 것을 green bar로 생각하고 구현을 진행했다. 호출부가 바뀌었을 때 코드를 호출 안하는 채로 둬도 error가 발생 안해서 print를 넣는게 더 유용하다고 생각했다.
22, 23장.
책 설명에는 ‘테스트를 실행해본다’가 다 생략되어있어서 새로운 테스트 만들 때마다, 리팩토링을 할 때마다 알아서 실행해야함…. 특히 summary는 print해서 확인을 해봐야한다.