1. 요구사항을 파악하지 않고 단계만 밟으면 된다.
2. TDD는 설계를 안해도 된다

저도 요구사항 꼼꼼히 읽고 정리하고 이러는건 싫어 하는데, 아마 하나씩 단계를 거치면서 진행되니 전체적인 설계가 필요없고, 이해하기 쉬운것부터 구현할수 있어서 이렇게 받아들이나보네요. 저도 요구사항 분석 참 귀찮더라구요. 그렇지만 테스트 케이스를 만들때 분량이 적당해야지 너무 커지만 더 어렵기만 하겠죠. 그래서 TDD에서 요구사항에 대한 분석, 정리, 순서는 아주 중요합니다.(순서정도야 틀리면 바꾸면 되니까 뭐--;)

설계를 미리한다는데 논란이 좀 있더군요. 책에서는 설계를 미리한다는 얘기는 없었지만, 아 그게 참 어렵습니다. 이미 이만큼 머리속에 생각이 나 버린사람들도 곤란하고, 잘모르는 사람도 처음에는 잘 따라하지만, 나중에 구현한 분량이 많아지면, 자기가 만든 코드도 잘 해어나지 못하는 그런 상황이 발생하더군요. 그렇다고 TDD의 가르침을 이어 받고자 엄청난 수련의 결과 득템!하자는건 뭐 TDD 라이센스 자격증이 있어서 평생 먹고 살걱정 안하는 그런것도 아니고, 누구든지 따라하기 쉬어야 많이들 하겠죠. 너무 뭔가 요술을 부릴것 같은 느낌은 좋지 않습니다(물론 된다면야 ㅋ). 구체적인 메소드 이름까지는 아니고, 어느 클래스가 어떤 일을 도맏아서 하겠다. 이 클래스는 저클래스와 관계를 가진다 정도까지는 있어야 진행하기 좀 더 수월하고, 잦은 설계 변경을 막는게 아닐까 하네요.

물론 TDD로 잘게 쪼개서 잘 진행하면 설계 변경도 어느 정도 수월하고 고친코드를 다시 검증하는 방법도 쉽지만, 뭐 말이 쉽지 한번 해보면 그닥 쉽지도 않습니다.역시 달인 김병만 선생의  "해봤어요? 안해봤으면 말을 마세요~"의 명언이 생각이 납니다. 그냥 다른것(폭포수처럼 한꺼번에 만들어버린것)보다는 수월하다는 얘기죠.

배워나가는 단계라 뭐라 말하지는 못하겠지만, TDD를 배우면서 가장 좋은 경험을 일을할 Task를 잘게 쪼갠다는 겁니다. 잘게 쪼개면 쪼갠만큼 덜 복잡하고, 그다지 뛰어난 두뇌를 가지지 않고도 생각을 할수가 있거든요. 거진 단기기억 상실 증세를 보이는 처지라 정말 이게 너무 좋습니다. 그리고 잘게 쪼게어 클래스가 정말 캡슐화가 된다면 이걸가지고 다른 클래스 인스턴스와 관계를 좀더 수월하게 맺어줄수 있지 않을까 하네요. 이 단계에 TDD가 지대한 공헌을 하겠지만, 마술처럼 이걸 하면  이게 된다! 이런것보다 이렇게 하니까 이런능력이 생기네? 이쪽으로 생각하는게 좀더 좋지 않나 싶네요.

그냥 TDD가 다 해준다라는 환상을 좀 깨보려고 쓴글인데 적절히 썼나 모르겠네요. 중요한건 TDD가 내 능력을 좀 좋게 훈련시킬 좋은 이론인건 사실이라는거죠. TDD를 얘기를 하면서 정작 Test코드를 를 작성하는 잇점은 쓰지 않았네요. 뭐 다들 아시죠?

추신: 너무 TDD기술에만 집중을 해서 좀 넓게 보자는 취지인데 음 그닥 글을 쓴 이유는 반영못했네요. 휴~디티네염.