하지만 나라면 BDD는 인수 테스트나 통합 테스트에 이용하는 것이 더 적당할 듯. 개발자들은 여전히 '테스트'를 작성해서 TDD로 개발하고...

인수 테스트가 무언가요? '_'

FIT와 BDD가 좀 겹치는 부분이 있다는 느낌이 있긴 했어요. 인수테스트도 TDD의 한 부분이라고 생각해서. :-)

TDD를 좀 큰 주기로도 생각하는 사람들도 있기는 한데 (틀리다고는 생각하지 않지만) 적어도 켄트백의 책에서는 짧은 주기 (수십초에서 길어 봤자 수분) 안에 끝나는 결정에 대한 테스트를 말하고 있다고 생각해. 인수테스트는 아무리 XP같이 반복 주기가 짧은 방법론이라고 해도 일주일인데...

그 짧은 주기는 TDD 훈련할때 아닌가요. TDD라는게 결국 피드백에 대한 이야기이라고 생각해서. 전략적으로 결정할 문제. 라고. 생각되어지는 되요. (잘은 모르지만.)

피드백에 대한 얘기지... 더 정확히 말하면 피드백을 빨리 얻자는... TDD를 확장하는 논의에 대해서 반대하지는 않지만 인수테스트에 테스트 자동화 기술을 사용하는 것과 극히 짧은 주기의 TDD를 쓰는 것과는 성격이 무척 다르다고 생각해... 예를 들어 오늘 내가 작업할 것을 테스트로 작성하고 하루 종일 작업한 다음에 테스트를 돌리는 것이 TDD일까? 난 아니라고 봐.

아 제가 TDD에 어떤 식견이나 아는게 없어서 자꾸 댓글 다는게 거시기 하긴 하지만요. :-)

전 단지 피드백을 빨리 얻기 위해서라고는 생각하지 않습니다. 사실 저는 켄트백의 TDD 책도 제대로 보지 못했네요. :-)

ㄴ 이 부분은 내일 함께 이야기 하도록 해요. :-) 사실 요즘 생각은 TDD가 무언지..등등이 중요한게 아닌듯. ㅎㅎㅎ

이미 말했지만 TDD를 확장하는 논의는 언제나 가능하다고 봐. 하지만 적어도 TDD를 제안한 사람의 의도와 추가적인 확장은 구분되서 논의 되어야 혼돈이 안 생길 것 같아. 같은 단어를 서로 다르게 이해하고 있다면 문제가 좀 되니까.

아! 내일이군. 오키...

실장님의 내용이 저자의 의도인가요? 흠. 책은 안봐서 믿음이 안가요. ㅎㅎㅎ

ㄴ 농담이구요. ;-)

제가 알고 있는 TDD은 몇줄 안되는 군요.

"TDD is an awareness of the gap between decision and feedback during programming, and techniques to control that gap." -Kent back.

ㄴ 사실 한줄. -_-;

"What if I do a paper design for a week, then test-drive the code? Is that TDD?" Sure. it's TDD. You were aware of the gap between decision and feedback, and you controlled the gap deliberately.

이것도 켄트 아저씨 말씀~~

둘 다 저자 서문에 있는 말이야. TDD가 뭔지 얘기할 때 잊지 말아야 할 몇가지 중에 포함되는 중요한 언급이라고 생각해.

두번째의 'a week'이 혹시 feedback 기간이라고 생각할지도 모르겠는데 그게 아니고 1주일 동안 생각하고나서, 그러니까 미리 설계를 대략하고나서 TDD로 코딩하는 것도 TDD라고 할 수 있다는 의미... 여전히 TDD의 주기는 수십초에서 수분 적어도 한시간은 안 넘는 짧은 주기인거지.

design for a week 가 decison이고 test-drive the code 가 feedback 이라면 TDD의 주기이고 unit testing하는 주기는 딴거 아닐까요? 하지만 TDD 훈련할때는 책에 있듯이 짧게 하는 훈련이 필요 할듯 해요.

우리 수요일날은 그냥 놀아요 ㅎㅎㅎ

저자 서문을 함 쭉 읽어보셔... 그리고 원래 우리는 이러면서 놀잖아. -_-