TDD에서 테스트작성 시점에 대하여...

[임병인(포데브)]

안녕하세요. 주제글을 올려보긴 처음인데 최근 어떤 글에 댓글을 달다가 관련주제와 다른 길로 빠져들어 새로운 주제에서 토론하는게
맞겠다싶어 글을 씁니다. 아이폰에서작성하는거라서 오타가 있을수도 있는데 양해해주세요.

일단 저의 논지는 TDD에서는 테스트작성을 먼저하도록 하고 있으나 반드시 그럴필요는 없다는 것입니다.

결과를 쉽게 예측가능하다면 테스트를 먼저 작성할수 있지만 그렇지 않은 상황도 있기 때문에 테스트 작성의 순서보다 테스트를 작성하
고 수행한다는데 더 큰 목적을 둬야한다는거죠. 물론 테스트를 먼저작성하면 보다 테스터블하고 코드커버리지가 높고 누락되는 항목이
줄어들게 됩니다. 만약 순서가 TDD실천의 판단기준이라면 항상 테스트를 먼저 작성해야 한다는 압박과 결과를 쉽게 예측하지 못하
는 상황에서는 먼저 작성하는것 조차 쉽지않을 것입니다.

강의중 수강생이나 프로젝트 팀원들에게서 받는 질문중에 테스트를 항상 먼저 만들어야 하나요? 란 질문을 받곤합니다. 그때 전 이렇
게 얘기하곤합니다.
"절차와 실천방법을 이해하고 실행하는것은 중요합니다. 그러나 그 프레임에 갇혀 근본적인 목적을 잊어버리면 안됩니다. 상황에 따
라 적절한 절차와 방법으로 변경하여 목적을 달성하는게 중요합니다"

어느분이 애자일을 이렇게 비유한적도 있습니다.
"태권도의 품세를 익히는것은 중요하지만 실전에선 품세대로 하지않는다."
TDD의 근본적인 목적은 테스트에 있는것이 아니라 오류가 최소화된 소프트웨어 개발이지 않을까합니다. 그러므로 작성의 순서보다
테스트를 한다는데 더 큰 목표를 둬야 하지 않을까요?

제가 TDD의 전문가가 아니어서 많은분들의 의견을 듣고 저의 생각도 정리했으면하는 맘으로 주제글을 올립니다.

[이동인]

결과를 예측할 수 없어서 테스트 코드를 먼저 만들 수 없다면 무엇을 해야 하는지도 모르는 상황에서 코딩을 한다는 이야기가 됩니다.

TDD에 기술적인 부분을 익히기 위해 먼저 코딩을 해보고 테스트를 만드는 것은 이해가 가지만 

익힌 후에도 그런 식으로 TDD를 사용한다면 TDD를 사용하므로 얻을 수 있는 이익이 많지 않을 것이라 생각됩니다.

2012년 3월 28일 오전 9:37, 임병인(포데브) <brianlim...@gmail.com>님의 말:

[정원천]

안녕하세요. 처음으로 xper에 글타래에 댓글을 올려 봅니다.^^;

 

TDD를 업무에 적용해본 경험으로는 개발 진행하는 차원에서는 실제 코드를 작성하고 나중에 테스트를 추가하는 것이 편한 점이 있었습니다.

아무래도 그간 몸에 익어서 그렇게 느껴지는 것 같습니다.

 

테스트를 먼저 작성할때는 불편하고 번거로운 느낌입니다.

다만 테스트를 작성하고나서 코드를 작성했을때는 코드의 설계자체가 틀려지는 경험을 여러 번 했습니다.

과연 테스트를 만들지 않고 코드 먼저 작성했을 때 이러한 구조의 코드가 나올수 있었을것인가 자문해보면 그렇지않았을 것이다란 결론이 나온적이 많았습니다.

그래서 최근에는 가능하다면 테스트를 먼저 작성하고나서 실제코드를 작성하려고 의식적으로 노력하고 있습니다.

[임병인(포데브)]

빠른 의견에 먼저 감사드립니다.
TDD에서 테스트작성의 순서는 중요하며 먼저 작성해야만 TDD의 많은 이익을 얻을 수 있다는 의견이죠?

결과를 예측하기 어렵다는 상황이 꼭 무엇을 해야하는지 모르는 상황만 있는게 아니라는 변을 달고 싶습니다.
이건 또 다른 토론주제가 될법한 문제인데 단위테스트의 단위와 크기의 문제입니다.
각각의 테스트 마다 데이터셋을 마련하고 유지하면 좋은데 비즈니스로직이 복잡하면 그 데이터셋을 마련하는것도 상당히 어렵게 됩니
다.
이럴 경우 저는 일단 테스트케이스 작성을 미루고 로컬환경에 배포한후에 비즈니스로직의 오류여부를 판단합니다.
그런 다음 적절한 테스트데이터를 생성하고 테스트케이스를 작성합니다.
이 경우 테스트케이스는 나중에 만들어지지만 이후 로직의 변경이나 리팩토링에서 많은 이익을 줍니다.

On 3월28일, 오전9시51분, 이동인 <leedong...@gmail.com> wrote:
> 결과를 예측할 수 없어서 테스트 코드를 먼저 만들 수 없다면 무엇을 해야 하는지도 모르는 상황에서 코딩을 한다는 이야기가 됩니다.
>
> TDD에 기술적인 부분을 익히기 위해 먼저 코딩을 해보고 테스트를 만드는 것은 이해가 가지만
>
> 익힌 후에도 그런 식으로 TDD를 사용한다면 TDD를 사용하므로 얻을 수 있는 이익이 많지 않을 것이라 생각됩니다.
>

> 2012년 3월 28일 오전 9:37, 임병인(포데브) <brianlim.next...@gmail.com>님의 말:

[임병인(포데브)]

"테스트를 항상 먼저 작성하지는 않지만 먼저 작성하는것이 더 많은 이익을 주며 그렇게 익숙해지려고 한다."는 의견으로 정리해도
될까요?
그러므로 TDD에서 테스트 작성의 순서는 중요하다는 의견. 감사합니다.

On 3월28일, 오전10시01분, 정원천 <arisu1...@gmail.com> wrote:
> 안녕하세요. 처음으로 xper에 글타래에 댓글을 올려 봅니다.^^;
>
> TDD를 업무에 적용해본 경험으로는 개발 진행하는 차원에서는 실제 코드를
> 작성하고 나중에 테스트를 추가하는 것이 편한 점이 있었습니다.
>
> 아무래도 그간 몸에 익어서 그렇게 느껴지는 것 같습니다.
>
> 테스트를 먼저 작성할때는 불편하고 번거로운 느낌입니다.
>
> 다만 테스트를 작성하고나서 코드를 작성했을때는 코드의 설계자체가 틀려지는
> 경험을 여러 번 했습니다.
>
> 과연 테스트를 만들지 않고 코드 먼저 작성했을 때 이러한 구조의 코드가 나올수
> 있었을것인가 자문해보면 그렇지않았을 것이다란 결론이 나온적이 많았습니다.
>
> 그래서 최근에는 가능하다면 테스트를 먼저 작성하고나서 실제코드를 작성하려고
> 의식적으로 노력하고 있습니다.
>
> From: xp...@googlegroups.com [mailto:xp...@googlegroups.com] On Behalf Of
> 이동인
> Sent: Wednesday, March 28, 2012 9:51 AM
> To: xp...@googlegroups.com
> Subject: Re: TDD에서 테스트작성 시점에 대하여...
>
> 결과를 예측할 수 없어서 테스트 코드를 먼저 만들 수 없다면 무엇을 해야
> 하는지도 모르는 상황에서 코딩을 한다는 이야기가 됩니다.
>
> TDD에 기술적인 부분을 익히기 위해 먼저 코딩을 해보고 테스트를 만드는 것은
> 이해가 가지만
>
> 익힌 후에도 그런 식으로 TDD를 사용한다면 TDD를 사용하므로 얻을 수 있는
> 이익이 많지 않을 것이라 생각됩니다.
>

> 2012년 3월 28일 오전 9:37, 임병인(포데브) <brianlim.next...@gmail.com>님의

[이광운]

TDD에 대한 제 경험을 말씀드리면

사업팀에서 일정에 민감해하고 일부 버그가 있더라도 빨리 화면으로 기능을 확인하고
오픈하고 싶어사면 사실 테스트를 먼저 작성하기 어려운 점이 있습니다.

그래서 제 스스로 타협한 부분이 "돈", "상용과 테스트 구분", "마켓 구분"과 관련해서 실수하면 치명적인 부분은
TEST를 먼저 작성하고 나머지는 기존(?)대로 코딩을 통해 기능을 먼저 구현하고 있습니다.

이러다보니 기술채무가 늘어나서 답답하긴하죠.

첫 술에 배부를 수 없다고 점차 점차 테스트를 먼저 작성하는 쪽으로 가려고 하고는 있습니다.

다들 TDD의 정석은 아시겠지만 현재 회사, 부서, 팀의 분위기에 맞춰서
테스트를 먼저 작성하실 지, 나중에 테스트를 작성할 지 맞춰서 유연하게 가시면 좋을 것 같습니다.

2012년 3월 28일 오전 10:51, 임병인(포데브) <brianlim...@gmail.com>님의 말:

[Freddie Park]

안녕하세요.
저도 아이폰에서 보내는거라 오타에 양해 부탁드립니다.

저는 테스트케이스를 만드는것과 TDD는 동의어가 아니라고 생각합니다. 테스트케이스는 그 자체로 의미있고 많은 이점을 가져다 주지만, 제가 생각하는 TDD는 설계과정으로서의 테스트케이스의 작성입니다.

비지니스 로직에 따라 테스트 픽스쳐를 마련하기가 어려울 수 있다는 부분에는 동의합니다. 저같은 경우는 전에 멀티미디어 프레임워크쪽을 개발할 때, 오디오나 비디오 데이타에 대해 도저히 픽스쳐를 생각할 수가 없었습니다.

그렇다 하더라도, TDD의 핵심은 테스트를 "먼저" 작성하는 것에 있다고 생각합니다.
단순히 유닛테스트만을 생각한다면, 버그를 줄여주고 리팩토링을 쉽게 해주는 안전망 정도로 생각할 수 있습니다. 그러나 TDD는 안전망의 개념을 넘어서, 테스트의 작성이 설계의 과정이라는 것에 초점을 두고있다고 봅니다. 테스트를 "먼저" 작성함으로서 설계의 이점을 취하는 것이, TDD의 핵심이라고 생각합니다.

먼저 말씀드렸던 오디오/비디오 데이타의 경우에는, 순서에 상관없이, 테스트를 나중에 작성하더라도 테스트 데이타는 만들기가 어려웠습니다. 그러나 나중에라도 테스트 데이타를 만들 수 있다면, 먼저 작성하는 것도 가능하지 않을까 하는 것이 제 생각입니다.

Best regards,
Freddie

2012. 3. 28. 오전 10:23 임병인(포데브) <brianlim...@gmail.com> 작성:

[gyehong park]

병인님 안녕하세요.

사실 어제 별도로 스레드 만들어서 같이 이야기를 해 보고 싶었습니다.

이렇게 먼저 얘기를 해 주셔서 기뻤습니다. ^^*

TDD에서 테스트를 먼저하면 얻어지는 이익들이 많이 있다는 것은 다들 잘 알고 있을 것 같습니다.

하지만, 병인님의 글에는 또 다른 뭔가가 있는 듯한 느낌이 듭니다. 저는 그것을 알고 싶습니다. 

그래서 궁금한 것들이 있습니다.

1. TDD 활용을 완벽하게 할 수 있는 사람이 있을 때도, Test를 나중에 만들어야 하는 경우가 있을까요? 있다면, 이해하기 쉽게 설명해 주시면 좋겠습니다.

2. TDD, 단위 테스트, 인수 테스트에 대해서 어떠한 정의를 갖고 계신가요?

저는 병인님이 1번 질문에 대해서 "그렇습니다"라고 말한다고 생각하고 있습니다.

2번 질문은 Freddie Park 님과 비슷한 의견에서 드렸습니다.

좋은 하루되세요~

2012년 3월 28일 오전 10:51, 임병인(포데브) <brianlim...@gmail.com>님의 말:

"테스트를 항상 먼저 작성하지는 않지만 먼저 작성하는것이 더 많은 이익을 주며 그렇게 익숙해지려고 한다."는 의견으로 정리해도

[Youngrok Pak]

지난 번 쓰레드 보면서 이거 독립 주제로 토론하면 좋겠다는 생각을 했는데, 마침 적절하게 쓰레드로 뽑아주셨네요. 저는 이게 매우 중요한 포인트를 지적하신 거라고 봅니다. 다만, 이번 글보다는 지난 번 글에서 좀더 명료하게 포인트가 드러나는 것 같은데요.

비즈니스 로직이라는게 이론처럼 단순하지 않습니다. 인수테스트 요건을 만들듯이 데이터 조건과 결과를 예상하는것은 상당히 어렵습니다. 더구나 처음접하는 비즈니스의 경우 동작하는 결과를 보면서 이해하기도 합니다.

바로 이 부분입니다. 적절한 지적입니다. 사실 어떻게 동작해야 하는지 알기 위해서는 해당 비즈니스에 대한 이해가 필요합니다. 그리고 그 이해를 얻는 가장 좋은 방법은 직접 사용해보는 것이구요. 어떻게 동작할지를 먼저 정의하고, 동작하게 개발하는 게 TDD인데, 어떻게 동작해야할지 모르기 때문에 먼저 동작하게 만들어서 돌려봐야 한다는, 닭이 먼저냐 달걀이 먼저냐의 상황인 거죠.

이걸 두고, 어떻게 동작해야 할지 모르는 상황 자체가 잘못이라고 이야기할 수도 있겠으나, 새로운 비즈니스라면 모르는 게 정상이고, 또 모른다는 관점에서 접근하는 것이 더 바람직한 접근이죠.

예를 하나 들어본다면, 저는 지금 모바일 채팅앱을 개발 중인데, 채팅방에서 위로 스크롤하면 이전 메세지를 보는 중에 새 메세지가 오면 스크롤을 내려서 새 메세지를 보여주는 게 합리적이라고 생각했습니다. 그런데, 실제로 그렇게 개발해서 돌려보니까 이전 메세지를 찾아보는 중에 새 메세지가 와서 스크롤되버리면 매우 짜증이 나더군요. 그래서 그 기능을 뺐더니, 이번에는 이전 메세지를 보는 중에 새 메세지가 왔는지 몰라서 대화가 한참 진행되는 걸 놓쳐버리더군요. 이건 이거대로 짜증이 났습니다. 그래서, 중간 해결책으로 스크롤을 한 화면 이상 했으면 이전 대화를 열심히 살펴보는 중이라고 보고 새 메세지가 와도 무시하고, 한 화면이면 일시적인 거라고 보고 스크롤을 내렸습니다. 그러니까 조금 쓸만하긴 한데 뭔가 아쉽더군요. 그런데, 카톡을 보니까 아주 깔끔한 해결책을 내놨더군요. 스크롤 중에 새 메세지가 오면 아래에 팝오버로 떴다가 사라집니다. 훌륭한 해결책이죠.

이런 진화 과정을 TDD로 한다면 효율적일까요? 써보면서 아니다 싶어서 바꿀 때마다 새로 테스트 케이스를 작성하는 것보다는 바로바로 코드를 고쳐서 실시간으로 확인해보는 게 더 빠릅니다. 

또 하나 예를 든다면, 예전에 환불 처리 절차를 개발한 적이 있었습니다. 처음에는 환불 처리 절차를 CS 담당자에게 설명을 듣고 개발에 들어갔는데, 일단 환불 요청을 어떤 식으로, 어떤 정보를 받아야 할지 모르겠더군요. 그래서, 일단 환불 목록 조회부터 만들어서 담당자에게 보여주니 이것저것 코멘트를 해 줍니다. 그러니 좀 알 것 같아서 환불 요청 기능을 추가하고 좀 돌려보니까 필드가 몇 개 더 필요한 것처럼 보이더군요. 그래서 담당자에게 물어보니까 필요한 게 맞다고 확인해줘서 또 추가합니다. 이런 식으로 몇 번 피드백을 받고 나니까 그럭저럭 감을 잡았는데, 그 과정 중에 코드가 어지러워져 있고, 가끔만(?) 동작하더군요;; 그래서 이 때부터 TDD를 시작해서 TDD로 마무리를 지었습니다. 

이렇게 "어떻게 동작할지"에 대한 직관을 얻는 과정이 TDD보다 선행되어야 합니다. 불확실한 비즈니스일수록, 특히 저희 같은 스타트업일수록 더 그렇구요. 초기에는 quick & dirty를 통해 컨셉을 잡아내는 과정이 중요하죠. TDD는 프로젝트 전체를 완성하는 속도를 높이는데 도움을 주지만, 초기 프로토타이핑할 때는 TDD 없이 속도를 더 올릴 수 있습니다. 설령 그 이후에 전체 프로젝트 속도가 늦어지더라도 proof of concept를 앞당기는 게 더 중요하죠. 애자일에서는 이런 과정을 spike solution이라고 부르기도 하고(주로 기술적인 과제에 대해서 쓰지만) 프로토타이핑, tracer bullet 등으로 부르기도 하는데, 여튼 "제대로" 개발하기 전에 무언가 동작하는 코드를 만들어보는 게 필요하다는 것입니다.

그런 면에서 TDD로 바로 개발을 할 수 없는 상황도 많이 존재한다는 점, 동의합니다.

그러나, 여전히 테스트를 나중에 작성해도 괜찮다는 것에는 동의하지 않습니다. 여전히 TDD는 테스트를 먼저 작성할 때 가치가 있고, 동작하는 코드에 나중에 붙이는 테스트의 가치는 그리 크지 않다고 봅니다.

흔히 TDD가 결함률을 낮춰주며, 이게 TDD의 주요한 장점으로 언급되는데, 저는 여기에 동의하지 않습니다. 제가 경험/관찰해본 프로젝트에서 TDD와 결함률의 상관 관계는 거의 없었습니다. 오픈소스 프로젝트를 봐도 아마 비슷할 겁니다. TDD로 하고 있는 오픈소스도 이슈 트래커에는 이슈가 가득하고 메일링리스트는 아우성이죠. 3년 전까지 TDD를 몰랐을 것으로 추정되는 애플 개발자들이 만든 소프트웨어는 3년 전까지 zero defect에 가까웠던 반면, 상당히 수준 높은 TDD로 개발된 이클립스는 버그 투성이죠. 

제가 보는 TDD의 핵심 이득은 좋은 설계를 빠른 속도로 만들어낼 수 있다는 것인데, 나중에 테스트를 붙이면 그 이득은 거의 얻지 못합니다. 오히려, 반대로 시간을 낭비하는 결과를 만드는 경우도 흔합니다. 사실 제가 봐온 TDD 사례에서는 The Goal의 교훈을 잊고 있는 경우가 많았던 것 같습니다.

말씀하신 내용 중에 일단 코드를 먼저 돌려서 테스트 데이터를 뽑아내고 fixture로 사용한다는 것도 있었는데, 효율 면에서는 나쁜 방법은 아니라고 보지만, 그렇게 뽑아낸 데이터를 다시 손으로 정제를 하면 좀더 좋은 설계를 만드는데 도움이 됩니다.

저는 TDD를 할 때 fixture 작성에 50, 테스트 작성에 30, 실제 코드 작성에 20 정도로 시간 분배를 하는 게 괜찮다고 봅니다. fixture를 그냥 자동 테스트 돌리기 편하게 만드는 데이터 정도로 보는 경우가 많은데, 사실 FiT 등에서 이야기하는 fixture의 개념은 그 자체가 테스트 정의에 가깝죠. 그래서, db dump 뜬 데이터로 fixture를 쓰는 것보다는 테스트 케이스마다 fixture를 코드로 정의해주는 게 더 좋고, 그러면서 중복만 잘 제거하면 오히려 더 유연하게 조작할 수 있어서 더 편리하기도 합니다.

모순되는 것 같은 이 두 이야기를 조합하는 방법은, 모드를 분리하는 것입니다. 개념을 탑재하기 전까지는 TDD 없이 일단 돌아가게 만들어보고, 돌려보면서 직관을 얻은 후, 제대로 개발하기 시작할 때 TDD를 하는 것입니다. 아마도 프로젝트 초기에는 quick & dirty 모드를 더 자주 해야 할 것이고, 점점 진행될수록 quick & dirty는 부분적으로만 사용하고 TDD가 주요 모드가 되겠지요. 어쨋든 충분한 직관을 얻었다면 TDD를 하되, TDD를 하는 동안은 Test First로 해야 의미가 있겠지요.

한 가지 사족을 덧붙이자면, 제가 4년 전부터 주장해온 바인데, TDD의 장점이 좋은 설계를 빠르게 만들어내는데 있다고 본다면, 그 장점을 TDD를 통하지 않고 얻는 방법도 여러 가지 있습니다. 함수형 언어의 장점도 TDD의 장점과 많은 부분 겹치고, 때때로 fixture를 열심히 작성하는 것만으로도 TDD의 핵심 효과를 다 얻을 수가 있습니다.

2012년 3월 28일 오전 10:51, 임병인(포데브) <brianlim...@gmail.com>님의 말:

"테스트를 항상 먼저 작성하지는 않지만 먼저 작성하는것이 더 많은 이익을 주며 그렇게 익숙해지려고 한다."는 의견으로 정리해도

[최영목]

이번 스레드를 관심있게 지켜보고 있었는데, 저 또한 테스트를 먼저 만드는 편이 좋다라고는 생각하지만 그렇게 하기 힘든 상황 또는 그렇게 하지 않아도 되는 상황이 존재할 수 있다고 생각합니다.

위에도 말씀하셨듯이 테스트를 먼저 작성하기 힘든 상황은 다음이 있을 수 있겠네요.

1. 무엇을 해야할 지 아에 모르고 있는 상황

 - 테스트 작성의 문제가 아니라 해야할 일을 모르고 있는 상황이죠. 이는 무엇을 할 지 먼저 정하면 되는 문제입니다. (해야할 것은 많지만 해당 시점에서의 범위의 문제이죠)

2. 비즈니스가 복잡하여 결과를 예측하기 힘든 상황

 - 이는 정말 작성하기 힘듭니다. 지난번 저도 이 부분에 대해서 NHN에서 오신 분이 테스트 세미나를 하실 때 문의드렸던 내용입니다. 그 분께서는 네이버의 검색결과를 예를 드시면서 설명을 해주시더군요. 답변은 "예측할 수 있는 범위까지 테스트 범위를 줄인 후 해당 부분을 테스트하고, 그 테스트된 부분을 호출하는 것은 호출검증(행위검증)을 통해서 테스트한다."라고 하시더군요. 저도 동감하는 부분입니다.

그렇다면 테스트를 먼저 만들지 않아도 되는 상황은 어떤 상황일까요?

먼저 테스트를 만드는 목적에 달려있다고 봅니다.

1. 제대로 동작하는 지 확인하기 위해서 (무엇을 해야할지 명확하게 안다는 가정하에)

2. 1번을 하기 위한 쉬운 구조(설계)를 이끌어내기 위해서

3. 리팩토링을 위해서

4. 기타...

2번을 제외하고, 단순히 1번만 위해서라면 나중에 해도 됩니다. (이 "나중에"라는 단어의 해석에 따라서 달라지는 데 이는 아래에서 다시 말씀드리겠습니다.) 구현 전에도 만들 수 있다면 구현 후에도 못 만들리는 없죠. (구조를 제외했을 경우입니다.)

2번을 위해서라면 이 또한 나중에 해도 됩니다. TDD를 오래하다보면 테스트를 먼저 만들지 않더라도 2번을 만족시킬 수 있는 구조에 대해서 어느정도 익숙해져 있어서(주로 DI를 활용) 굳이 테스트를 먼저 만들지 않더라도 2번을 충족시킬 수 있습니다. 물론 테스트를 먼저 만들면 더욱 좋겠지만 "충분조건"이지 "필요조건"은 아니라는 뜻입니다. 또한 이 정도 익숙해질 때 쯤이면 테스트가 가능한 범위와 가능하지 않는 범위가 어느정도 보입니다.

3번이라면 반드시 먼저 만들수 밖에 없습니다 ㅡㅅ ㅡ;;;

다시 돌아와서 왜 나중에 만드는 것이 허용되느냐인데 이 나중에라는 단어를 많은 분들이 서로 다르게 생각할 수 있기 때문입니다. 지금 제가 위해서 언급한 "나중에"라는 것은 코드 구현상에서 테스트보다 구현 코드를 먼저 작성한다는 뜻입니다. (즉, 구현이 끝났다라고 보고할 때는 실제로 테스트까지 작성되고 검증된 이후입니다.)

하지만 말씀하신 "나중에"가 개발 프로세스상 개발단계 이후 테스트단계에서 작성하는 것이라면 저는 이 시점까지 테스트 작성을 미루는 것에 대해서는 반대합니다. 

마지막으로 테스트하고자 하는 범위와 난이도에 따라서 다를 수 있습니다. 예를 들어, 예제로 나오는 단순 두 수에 대한 덧셈,뺄셈 계산기 정도라고 생각했을 때 테스트를 먼저 만드나 구현 이후 테스트를 만드나 별로 큰 차이는 없습니다. 내가 구현하고자 하는 업무 로직을 아주아주아주 잘게 쪼게는 연습이 되어있을 수록 해당 부분에 대한 테스트 범위와 난이도는 줄어듭니다. (물론 구현이 끝난 전체 업무범위와 난이도는 동일합니다. 비유하자면 컴포넌트를 만드는 목적과도 유사하죠.)

하지만 테스트하고자 하는 범위가 커지고 난이도가 어려워질수록 테스트를 먼저 만들어야 하는 이유는 점점 커진다고 생각합니다. ^^

2012년 3월 28일 오후 12:05, Youngrok Pak <pak.yo...@gmail.com>님의 말:

[임병인(포데브)]

테스트를 먼저 작성하는 것이 더 많은 이득을 주며 좋은 설계를 유도할 수 있다는 의견과
[테스트를 "먼저" 작성함으로서 설계의 이점을 취하는 것이, TDD의 핵심이라고 생각합니다.]라는 의견에 공감합니다.

또한 "나중에 작성할 수 있다면 먼저 작성할 수도 있지 않겠나"는 의견에도 동의하지만 먼저 만드는 공수와 나중에 만든는 공수를
생각해보면 적당히 타협할 수도 있지않겠나? 싶은 것입니다. "반드시 먼저 만들어야 한다"는 프레임에 갇히기 보단 더 효율적이라
면 나중에 만들어도 되지 않을까요?

테스트를 먼저 만듬으로써 좋은 설계를 할 수 있다는 것이지 테스트를 먼저해야만 좋은 설계를 할수 있다는 것이 아니라는 논지입니
다.
획일적인 하나의 방법을 고수하기 보단 상황과 목적에 따라 적절하게 변형하여 적용하는 게 더 좋다는 거죠.
물론 이런 판단과 적용을 하기 위해선 원래의 절차와 방법을 알 필요가 있습니다.
마치 태권도의 품세를 평소에 연습하여 실전에 적용하는 것처럼 말이죠. 자유로운 몸짓처럼 보이지만 그 몸짓을 어느센가 몸에 밴 품
세의 응용일테니까요.

개발생산성과 품질향상을 위한 글로벌 기업의 애자일 도입 및 적용 사례
http://www.slideshare.net/wgshim/experience-report-agile-adoption-stories-in-lg-electronics

위의 자료를 보면 "성룡의 취권"과 "취객의 취권"이란 슬라이드가 있습니다.
제가 이해한 저자의 의도는 "성룡이 취권을 사용하기 위해서 부단한 노력과 수련을 하는 것처럼 애자일도 부단한 연습과 노력을 통
해 응용해야 한다"입니다.
우리 또한 연습하고 노력해야 하지만 그것을 실전에 도입할 때는 수많은 장벽과 반발에 부딪힙니다.
불완전하지만 적절한 타협점을 찾아서 이상적 방향으로 개선시켜 나가는 게 중요하지 않을까 합니다.

On 3월28일, 오전11시08분, Freddie Park <sorel...@gmail.com> wrote:
> 안녕하세요.
> 저도 아이폰에서 보내는거라 오타에 양해 부탁드립니다.
>
> 저는 테스트케이스를 만드는것과 TDD는 동의어가 아니라고 생각합니다. 테스트케이스는 그 자체로 의미있고 많은 이점을 가져다 주지만, 제가 생각하는 TDD는 설계과정으로서의 테스트케이스의 작성입니다.
>
> 비지니스 로직에 따라 테스트 픽스쳐를 마련하기가 어려울 수 있다는 부분에는 동의합니다. 저같은 경우는 전에 멀티미디어 프레임워크쪽을 개발할 때, 오디오나 비디오 데이타에 대해 도저히 픽스쳐를 생각할 수가 없었습니다.
>
> 그렇다 하더라도, TDD의 핵심은 테스트를 "먼저" 작성하는 것에 있다고 생각합니다.
> 단순히 유닛테스트만을 생각한다면, 버그를 줄여주고 리팩토링을 쉽게 해주는 안전망 정도로 생각할 수 있습니다. 그러나 TDD는 안전망의 개념을 넘어서, 테스트의 작성이 설계의 과정이라는 것에 초점을 두고있다고 봅니다. 테스트를 "먼저" 작성함으로서 설계의 이점을 취하는 것이, TDD의 핵심이라고 생각합니다.
>
> 먼저 말씀드렸던 오디오/비디오 데이타의 경우에는, 순서에 상관없이, 테스트를 나중에 작성하더라도 테스트 데이타는 만들기가 어려웠습니다. 그러나 나중에라도 테스트 데이타를 만들 수 있다면, 먼저 작성하는 것도 가능하지 않을까 하는 것이 제 생각입니다.
>
> Best regards,
> Freddie
>

> 2012. 3. 28. 오전 10:23 임병인(포데브) <brianlim.next...@gmail.com> 작성:

[CHAE.SW]

쓸까말까 한참을 고민 하다가 글을 씁니다.

그리고 좀 더 썼다가 '음...' 하면선 내용을 줄였습니다.

그래서 문맥적 오해가 있을 수도 있지만,  생각과 느낀 점 그냥 쓸게요. (너그럽게 봐주세요)

원래 그러면 안되지만 TDD만 딱 분리해 놓고 봤을 때 목표 효과에 대해서,

- 기획을 테스트 해보는 것과 기능에 맞게 개발하는 것은 조금 다른것 같아요.

- 개발 속도와 품질의 관계라던가, 개인이 개발할 수 있는 분량과 팀 레벨로 해야 하는 것도 접근이 조금 다른 것 같아요.

- TDD가 확실히 비용은 더 들더라구요. 열심히 빚 갚았는데 원금떼이는 경우도 많아요.

- To Be가 분명 -하다고 느낀- 경우와 해봐야 알 것 같은 경우는 말은 차이가 있지만 어떤식으로든 "추정예상"이 있으면 좀 더 몰입되는 것 같아요.

- UX는 확실히 어려워요. 테스트는? OMG!에요.

- TDD만 열심히 하려고 하면 TDD를 제대로 하기 어려워요.

- 프로그램을 잘 못하는 사람(=IT 초년생?)일 수록 TDD를 더 잘 해요. (정말이에요)

음...

네. 뭐 그렇습니다. : )

점심에 잠깐 산책 나갔다 왔는데, 날씨가 따뜻하니 좋더라구요.

well... Let's go out~!! 

[임병인(포데브)]

On 3월28일, 오전11시22분, gyehong park <gyehongp...@gmail.com> wrote:
> 병인님 안녕하세요.
>
> 사실 어제 별도로 스레드 만들어서 같이 이야기를 해 보고 싶었습니다.
> 이렇게 먼저 얘기를 해 주셔서 기뻤습니다. ^^*
>
> TDD에서 테스트를 먼저하면 얻어지는 이익들이 많이 있다는 것은 다들 잘 알고 있을 것 같습니다.
> 하지만, 병인님의 글에는 또 다른 뭔가가 있는 듯한 느낌이 듭니다. 저는 그것을 알고 싶습니다.
>
> 그래서 궁금한 것들이 있습니다.
>
> 1. TDD 활용을 완벽하게 할 수 있는 사람이 있을 때도, Test를 나중에 만들어야 하는 경우가 있을까요? 있다면, 이해하기 쉽게
> 설명해 주시면 좋겠습니다.

예측하신 대로 "그렇습니다."
Youngrok Pak 님이나 최영목 님께서 유형에 대한 적절한 예를 제시한 듯합니다. 저도 그런 상황들을 말씀드리고 싶습니
다.

>
> 2. TDD, 단위 테스트, 인수 테스트에 대해서 어떠한 정의를 갖고 계신가요?

Freddie Park 님의 글에 답글을 달았는데 유사의견이시라면 그 글을 통해 저의 의견을 말씀드린것 같습니다.
제가 말씀드리고 싶은 건 정의의 문제가 (물론 개념 정의는 중요합니다만) 아니라 프로젝트 수행과정 중에 테스트 작성의 순서에 대
한 문제입니다.
저의 논지는

1. 테스트를 먼저 작성할 수 있다면 먼저 작성하라.
2. 테스트를 먼저 작성할 수 없다면 구현후 작성해도 된다.

입니다.

[TDD의 근본적인 목적은 테스트에 있는것이 아니라 오류가 최소화된 소프트웨어 개발]에 있다는 저의 의견과
[TDD의 핵심 이득은 좋은 설계를 빠른 속도로 만들어낼 수 있다는 것]이라는 Youngrok Pak 님의 의견
[테스트를 "먼저" 작성함으로서 설계의 이점을 취하는 것이, TDD의 핵심]이라는 Freddie Park 님의 의견 등 많은 분
들의 의견중에
공통되는 것은 테스트가 목적이 아니라 테스트로 인해 얻게될 "무엇"(오류가 최소화된 소프트웨어 개발, 좋은 설계를 빠르게 만들
어 내는 것 등)이며
테스트는 "무엇"을 이루기 위한 충분조건인가, 필요조건인가에 대해서 저는 충분조건이라는 의견입니다.
테스트는 "무엇"을 이루기 위한 하나의 수단이지 전체가 될 수 없다는 의견에서 토론의 주제로 띄운것입니다.

갑자기 이번 토론에 참여하신분들과 Off 모임을 갖고 싶다는 생각이 불현듯 듭니다.
아! 오늘인가요? ㅠㅠ 정모가 ... 갑작스런 컨설팅일정으로 강남으로 오긴했는데 신청을 하지 못했네요. 불청객으로 참여해도 될려
나...

>
> 저는 병인님이 1번 질문에 대해서 "그렇습니다"라고 말한다고 생각하고 있습니다.

> 2번 질문은* Freddie Park *님과 비슷한 의견에서 드렸습니다.
>
> 좋은 하루되세요~
>
> 2012년 3월 28일 오전 10:51, 임병인(포데브) <brianlim.next...@gmail.com>님의 말:

[June Kim (김창준)]

2012/3/28 임병인(포데브) <brianlim...@gmail.com>

안녕하세요. 주제글을 올려보긴 처음인데 최근 어떤 글에 댓글을 달다가 관련주제와 다른 길로 빠져들어 새로운 주제에서 토론하는게
맞겠다싶어 글을 씁니다. 아이폰에서작성하는거라서 오타가 있을수도 있는데 양해해주세요.

안녕하세요.

 

일단 저의 논지는 TDD에서는 테스트작성을 먼저하도록 하고 있으나 반드시 그럴필요는 없다는 것입니다.

참고로 켄트 벡은 XP 2.0(Extreme Programming Explained 2판)에서 TDD 대신 TFP(Test First Programming, 역서에서는 "테스트 우선 프로그래밍")라는 말을 써서 의도적으로 테스트가 앞에 와야 함을 강조하고 있습니다. 저는 TFP와 짝을 이뤄, 반복적으로 코딩 후 자동화된 테스트를 만드는 것을 TLP(Test Last Programming)이라고 하고 있고, 이미 TLP의 효용에 대해 여러번 이야기한 적이 있습니다(http://agile.egloos.com/5299932 참고).

그리고 TDDBE를 쓸 당시 켄트벡의 표현을 빌자면, TDD의 정의는 생각보다 넓은 것 같습니다.

<인용>

TDD란 프로그래밍 도중 내린 결정과 그 결정에 대한 피드백 사이의 간격을 인지하고, 또한 이 간격을 통제할 수 있게 해주는 기술을 말한다. "일주일 간 종이에다 설계한 다음 코드를 테스트 주도로 개발한다면 이것도 TDD인가?" 물론, TDD다. 결정과 그에 대한 피드백 사이의 간격을 인지하고, 또 의식적으로 제어했기 때문이다.

</인용>

 

저는 프로그래밍할 때에 우리가 원하는 이상적인 것이 뭔지 생각해 보고 그걸 공유하며, 그것의 가장 에센스에서 종착지로 "계속 살아있는 상태를 유지하며"(저는 "살리고 원칙"이라고 부릅니다) 진행하면서 동시에 어떻게 하면 더 최단경로로 갈까, 저기가 정말 우리가 원하는 곳일까를 계속 찾으면서 현재 위치와 목표점을 확인해 나가는 것이 (광의의) TDD라고 봅니다. 그래서 최근의 Lean Startup에서 가설 세우고 빠르게 확인해나가는 과정도 TDD의 확장으로 봅니다. 저 자신은 TDD를 일종의 메타인지적 전략(meta-cognitive strategies/heuristics)라고 보는 것 같습니다.

결과를 쉽게 예측가능하다면 테스트를 먼저 작성할수 있지만 그렇지 않은 상황도 있기 때문에 테스트 작성의 순서보다 테스트를 작성하

결과를 예측할 수 없을 때에도 테스트를 먼저 작성할 수 있습니다. 사실 결과를 예측할 수 없다는 것은 있다/없다 식의 흑백이 아니고 스펙트럼이 있으며 결과에 대해 아무런 정보도 없는 경우는 존재하기 힘듭니다. 결과를 도출하는 순서에 대한 정보를 가지고 테스트를 만들 수도 있고, 결과를 보고 판단하는 우리의 휴리스틱스를 가지고 테스트를 만들 수도 있고, 결과 간의 일관성을 비교하는 테스트도 가능하고요. 사실 이 문제는 QA쪽에서, 테스트 오라클(Test Oracle)이 정확히 주어지지 않을 때 테스트할 수 있느냐는 문제와 비슷하고, 이 상황에서 테스트할 수 있는 방법은 많습니다. 

 

고 수행한다는데 더 큰 목적을 둬야한다는거죠. 물론 테스트를 먼저작성하면 보다 테스터블하고 코드커버리지가 높고 누락되는 항목이
줄어들게 됩니다. 만약 순서가 TDD실천의 판단기준이라면 항상 테스트를 먼저 작성해야 한다는 압박과 결과를 쉽게 예측하지 못하
는 상황에서는 먼저 작성하는것 조차 쉽지않을 것입니다.

저는 축어적으로 "자동화된 테스트 코드를 먼저 작성하는 것"이 TDD의 필요조건이 된다고 생각하지 않습니다. 반대로, 자동화된 테스트 코드를 먼저 작성하지만 TDD가 아닌 경우도 흔하다고 생각하고요.

강의중 수강생이나 프로젝트 팀원들에게서 받는 질문중에 테스트를 항상 먼저 만들어야 하나요? 란 질문을 받곤합니다. 그때 전 이렇
게 얘기하곤합니다.
"절차와 실천방법을 이해하고 실행하는것은 중요합니다. 그러나 그 프레임에 갇혀 근본적인 목적을 잊어버리면 안됩니다. 상황에 따
라 적절한 절차와 방법으로 변경하여 목적을 달성하는게 중요합니다"

저도 적극 동의합니다.

첨언하자면, "주먹이 운다" 같은 프로그램에 나온 길거리 싸움 경험 많은, 자칭 도시별 짱인 사람들이 이종격투기 프로 선수와의 1분 경기에서 왜 초등학생처럼 무력해 보이는지 생각해 봐야 합니다(유튜브 검색해 보시면 많이 나옵니다). 상황에 따라 적절한 절차와 방법을 취하여 목적을 취하려고 하는 사람들이 과연 어떤 의도적 수련(deliberate practice)을 해왔으며, 그 의도적 수련의 질은 어떠한가, 또 그 사람들의 상황파악능력(sense-making, situation-awareness)이 정확한가, 거기에서 얻는 피드백이 정확한가 등등의 문제 등도 고려되어야 하는 것 같습니다.

어느분이 애자일을 이렇게 비유한적도 있습니다.
"태권도의 품세를 익히는것은 중요하지만 실전에선 품세대로 하지않는다."
 TDD의 근본적인 목적은 테스트에 있는것이 아니라 오류가 최소화된 소프트웨어 개발이지 않을까합니다. 그러므로 작성의 순서보다
테스트를 한다는데 더 큰 목표를 둬야 하지 않을까요?

TDD가 코드의 질을 높여주고 결함율을 낮추는 데에 도움이 된다고 생각합니다(이에 대해서는 학계에서 많은 연구가 진행되고 있고, 그만한 가치가 있다 아니다는 의견이 양존하며 아직 판결을 내리기에는 이릅니다). 하지만, TDD에서 테스트가 QA 전문가들이 보는 테스트와는 큰 차이가 있다고 생각합니다. TDD로 개발을 한 사람들이 자신의 코드에 대해 과신(over-confidence)을 하는 경우, 그래서 큰 고생을 하는 경우를 종종 봤습니다.

 

제가 TDD의 전문가가 아니어서 많은분들의 의견을 듣고 저의 생각도 정리했으면하는 맘으로 주제글을 올립니다.

각각의 테스트 마다 데이터셋을 마련하고 유지하면 좋은데 비즈니스로직이 복잡하면 그 데이터셋을 마련하는것도 상당히 어렵게 됩니다.
이럴 경우 저는 일단 테스트케이스 작성을 미루고 로컬환경에 배포한후에 비즈니스로직의 오류여부를 판단합니다.
그런 다음 적절한 테스트데이터를 생성하고 테스트케이스를 작성합니다.
이 경우 테스트케이스는 나중에 만들어지지만 이후 로직의 변경이나 리팩토링에서 많은 이익을 줍니다.

만약 이런 이유로 테스트를 나중에 작성하는 것이라면 저는 위험성이 도사리고 있다고 생각이 듭니다. 말씀하신 경우에서 테스트를 만들기 어려운 것은, 테스트를 설명하는 언어가 지나치게 낮은 레벨이기 때문은 아닐까 생각해 봐야 합니다(테스트에도 DDD가 필요합니다). 비즈니스 로직이 복잡하여 데이터셋 마련하는 것이 어려운데, 코딩을 한 후에 코드를 통해 직접 테스트데이터를 생성하고 테스트케이스를 작성한다면 이 테스트는 GUI에서 capture&replay류 테스트의 단점을 고스란히 갖고 있습니다. 즉, 테스트의 유지보수 비용이 높아집니다.

테스트를 먼저 작성하건 나중에 작성하건 상관없이, 테스트 작성하고 유지하는 작업이 고통스럽지 않게 하는 방법을 계속 찾아야 한다고 봅니다.

제가 한 이야기를 요약하자면:

• 테스트를 나중에 하냐, 먼저 하냐만으로 TDD다 아니다를 이야기할 수 없다.
• TDD에서 Test라는 말이 있긴 하지만, 이것은 엄밀하게 말해 엉성한 테스트다. 자칫하면 과신할 수 있다.
• TDD를 좀 더 넓게 볼 수 있다.
• 테스트 자체도 DDD를 적용해서, 테스트 작성이 고통스럽지 않아야 한다.
• 테스트 결과를 예측하기 힘들 때에도 테스트 작성은 가능하다.
• TDD에 너무 얽매이지 않는 것이 필요하다. 그러면서 나의 상황파악능력, 의도적 수련이 어떻게 되고 있는지 확인해야 한다.

[matthew]

오늘 이야기 나누는 Hot Issue 이겠네요... off line 으로 많은 내용이 공유되기를

2012년 3월 28일 오후 2:45, 임병인(포데브) <brianlim...@gmail.com>님의 말:

--

Shim min su

 The master´s course ISA/SWT

Department of Computer and Information Communications Engineering
Kangwon National University
http://noogabar.com (Testing Team Blog) - Editor

Mobile: +82-10-9707-8548
e-mail: matthe...@gmail.com

 

[김동열]

요즘 두 가지 소스를 놓고 작업하고 있습니다. 둘 다 테스트코드는 있습니다.

하나는 10년전에 작성한 코드인데 TDD로 하지 않은 코드고...
다른 하나는 TDD로 만든 코드입니다.

TDD로 개발하지 않았던 코드... 뭘 고치거나 사용하려고 해도 욕이 나옵니다. (제가 개발했던 겁니다. ㅜㅜ)
설계차이 많이 납니다. -.-;

TDD 어렵습니다. 애자일 성숙도 맨 끝자락에 있습니다.
많은 고수분들도 계시겠지만 저는 TDD의 원칙은 지켜야한다고 봅니다.
아직 우리팀은 TDD의 변형을 이야기하고 싶지 않습니다.
그래서 저는 테스트 주도 개발이 아니라 테스트 먼저 개발이라고 말하곤 합니다. 자신도 쓰기 애매한 API는 만들 시도도 하지 말
자...

물론 기획 때 아이디어 검증을 위한 프로토타입은 TDD 하지 않습니다.
개발언어도 굳이 정해진 것으로 하지 않습니다. 개념 증명하고 프로토타입은 버립니다.

네. 저도 뭐 그렇습니다.

> > 2012년 3월 28일 오후 12:05, Youngrok Pak <pak.young...@gmail.com>님의 말:

> ...
>
> 추가 정보 >>

[임병인(포데브)]

> 그러나, 여전히 테스트를 나중에 작성해도 괜찮다는 것에는 동의하지 않습니다. 여전히 TDD는 테스트를 먼저 작성할 때 가치가 있고,
> 동작하는 코드에 나중에 붙이는 테스트의 가치는 그리 크지 않다고 봅니다.

Youngrok Pak 님의 의견 대부분에 동의하며 구체화 시켜주신점에 대해 감사드립니다.

[동작하는 코드에 나중에 붙이는 테스트의 가치는 그리 크지 않다]는 의견에 대해서... 고객에게 말할 때
==> "반드시 먼저 작성해야만 합니다." 와 "먼저 작성해야 하지만 나중에라도 작성해야 합니다." 에 대한 의견은 어떤가요?

[모순되는 것 같은 이 두 이야기를 조합하는 방법은, 모드를 분리하는 것입니다. 개념을 탑재하기 전까지는 TDD 없이 일단 돌아
가게
만들어보고, 돌려보면서 직관을 얻은 후, 제대로 개발하기 시작할 때 TDD를 하는 것입니다.]
==> "실용주의 프로그래머"에 '예광탄 프로젝트'라는 주제가 있습니다.
프로토타이핑이나 아키텍처 RI(Reference Implementation)를 할 때는 그 프로젝트 자체가 테스트나 검증하는 것
이기 때문에 버리는 코드이며 본 프로젝트를 위한 것입니다. 하지만 예광탄 프로젝트의 경우 그 자체가 프로젝트의 초석이 되고 빠
른 피드백을 위한 것입니다. 이 예광탄 프로젝트를 하는 목적은 고객도 분석설계자도 개발자도 무엇을 만들지 명확하지 않기 때문에
말그대로 한번 개발해 보는 것이죠. 그리고 동작하는 것을 보면서 구체화시켜나갑니다. 그러나 이 프로젝트의 특징은 버리는 코드가
아니라는 거죠. 즉, 제대로 개발하기 시작할 때 라는 경계가 없다는 것입니다. 물론 특정 시점부터 TDD로 전환 할 수 있습니
다. 저는 이런 상황에서는 이전에 만들어진 코드에도 테스트를 작성해둬야 한다는 의견입니다.

[아마도 프로젝트 초기에는 quick & dirty 모드를 더 자주 해야 할 것이고, 점점 진행될수록 quick & dirty

는 부분적으로만 사용하고 TDD가 주요 모드가 되겠지요. 어쨋든 충분한 직관을 얻었다면 TDD를 하되, TDD를 하는 동안은

Test First로 해야 의미가 있겠지요.]
==> 테스트없이 만들어진 코드에 대해서 TDD적 접근방법은 어떤게 있을까요?

많은 분들과 이런 토론을 하는 것 자체가 즐겁습니다. 참여하신 모든 분들께 다시한번 감사드립니다.

> 2012년 3월 28일 오전 10:51, 임병인(포데브) <brianlim.next...@gmail.com>님의 말:

>
>
>
>
>
>
>
> > "테스트를 항상 먼저 작성하지는 않지만 먼저 작성하는것이 더 많은 이익을 주며 그렇게 익숙해지려고 한다."는 의견으로 정리해도
> > 될까요?
> > 그러므로 TDD에서 테스트 작성의 순서는 중요하다는 의견. 감사합니다.
>
> > On 3월28일, 오전10시01분, 정원천 <arisu1...@gmail.com> wrote:
> > > 안녕하세요. 처음으로 xper에 글타래에 댓글을 올려 봅니다.^^;
>
> > > TDD를 업무에 적용해본 경험으로는 개발 진행하는 차원에서는 실제 코드를
> > > 작성하고 나중에 테스트를 추가하는 것이 편한 점이 있었습니다.
>
> > > 아무래도 그간 몸에 익어서 그렇게 느껴지는 것 같습니다.
>
> > > 테스트를 먼저 작성할때는 불편하고 번거로운 느낌입니다.
>
> > > 다만 테스트를 작성하고나서 코드를 작성했을때는 코드의 설계자체가 틀려지는
> > > 경험을 여러 번 했습니다.
>
> > > 과연 테스트를 만들지 않고 코드 먼저 작성했을 때 이러한 구조의 코드가 나올수
> > > 있었을것인가 자문해보면 그렇지않았을 것이다란 결론이 나온적이 많았습니다.
>
> > > 그래서 최근에는 가능하다면 테스트를 먼저 작성하고나서 실제코드를 작성하려고
> > > 의식적으로 노력하고 있습니다.
>
> > > From: xp...@googlegroups.com [mailto:xp...@googlegroups.com] On Behalf Of
> > > 이동인
> > > Sent: Wednesday, March 28, 2012 9:51 AM
> > > To: xp...@googlegroups.com
> > > Subject: Re: TDD에서 테스트작성 시점에 대하여...
>
> > > 결과를 예측할 수 없어서 테스트 코드를 먼저 만들 수 없다면 무엇을 해야
>

> ...
>
> 추가 정보 >>

[Jaepyoung Kim]

제 생각에는 임병인님께서 정말로 하고 싶은 말씀을 다음의 두문장으로 말씀하신거 같습니다.

1. 테스트를 먼저 작성할 수 있다면 먼저 작성하라.
2. 테스트를 먼저 작성할 수 없다면 구현후 작성해도 된다

하신 말씀에 공감은 가지만, 100% 동의는 안되는 말씀입니다.
저는 테스트를 먼저 작성하는 것이 충분한 설계를 했다고 생각합니다.
그래서 "테스트를 먼저 작성할 수 없다면 구현후 작성해도 된다" 말씀은 충분한 설계없이 코딩부터 시작해도 된다는 말로 저는 인식이 됩니다.
즉 테스트를 먼저 작성 할 수 없다는 것은 아직 개발할 수 있는 상태가 아니라고 생각합니다.
PSP(Personal Software Process) 에서도 자동테스트는 아니지만, 항상 테스트를 먼저 정의하고, 충분한 설계를 한 후에 구현을 시작하라고 하고 있습니다.

프로젝트에서 개발PM이 이렇게 말을 하면, 테스트를 작성 할 수 있음에도 불구하고 개발자의 코딩을 먼저하려는 특성상..
테스트없이 개발자들은 구현부터 들어가게 되기 때문에, 제가 개발PM이라면 그렇게 여지를 주고 싶지 않습니다.

저의 경우는 테스트를 나중에 작성하는 경우는 주로 게으름, 구현부터 먼저 하려는 개발자의 특성 때문이지 테스트를 먼저 작성할 수 없는 경우는 별로 없었던 거 같습니다.

2012/3/27 김동열 <dongyo...@gmail.com>

--
Jaepyoung Kim
(Cellular phone) 1-310-848-7774

[Jinsoo Jung]

관심있는 주제라 xper 가입 후 처음으로 글을 달게 되었네요^^

처음 뉴스그룹에 쓰는 글이고 초보인지라 두서없는 글이어도 양해부탁드립니다^^

오늘 아침에 우연히 보게된 Programmers stackexchange의 답변이 생각이 나서..

제 경험과 더불어서도 도움이 될만한 답변이 아닐까 싶어서 공유합니다.

http://programmers.stackexchange.com/questions/138987/do-i-need-to-test-everything 

위 쓰레드에서 언급된 답변에 있는 것과 같이

저 또한 TDD는 단순히 "테스팅"에 대한 것이 아니라 

"디자인"에 대한 것이라고 생각합니다.

"테스트"를 먼저 작성하는 것은 

단순히 구현물의 정상적인 동작의 검증 뿐만 아니라..

구현하고자 하는 대상이 어떻게 동작을 해야하고..

이를 위해 어떠한 인터페이스를 사용할 것인가에 대해서 

구현하기 전에 미리 "디자인"하는 과정을 반드시 수반하도록 강요합니다.

따라서 테스트를 먼저 작성한다는 것은 

곧 자신이 구현할 대상에 대한 심도있는 분석을 수반하게 하고..

이는 곧 비지니스 로직에 대한 정확한 이해, 

그리고 그 이해에 대한 "분석 결과물"을 작성한다는 것이라고 생각합니다.

추가적으로 아시다시피 테스트를 먼저 작성하게 되면 

"테스트"를 쉽게 하기 위한 모듈의 구조를 생각하게 되고..

그 결과는 좀 더 객체지향적인 코드로 이어지는 경우도 많은 것 같구요..

따라서 TDD에서  "테스트"를 먼저 작성하기라는 실천 방안은..

TDD를 통해 추구하고자 하는 근본적인 방향을 담고 있는 

매우 적절하면서도 중요한 가이드라인이라고 생각합니다.

물론 실제적으로는 여러가지 요인에 의해서(시간, 이런 저런 상황..) 

테스트를 먼저 작성하는 것이 어려운 상황이 있다는 것은 

충분히 이해하고 저 또한 그런 상황들을 겪고 있습니다만..

개인적으로는 제 능력이 부족해서 현실과 "타협"을 하고 있다고 자책하고 있는 편이라..

언젠가는 그 습관이 몸에 배길 기다리면서 수련하고 있습니다..ㅎㅎ;;

결론적으로 병인님께서 말씀해주신 것처럼 TDD의 근본적인 목적 중에 하나는 테스트에 있는것이 아니라 오류가 최소화된 소프트웨어 개발입니다만.

TDD의 또다른 근본적인 목적(혹은 이점이랄까요?..디자인적인 측면, 생산되는 코드의 품질,리팩토링 지원 기타 등등)을 보다 효율적으로 지원하기 위해서는 테스트 작성의 순서 또한 중요하다고 생각합니다.

[Sangcheol Hwang]

TDD를 잘 아는건 아니지만 그냥 비슷한 생각 하나 공유합니다.

테스트 코드가 언제 가장 유용한가? 코드가 가장 많이 변할때 유용하다고 생각합니다.
코드가 충분이 리팩토링 되어서..'아 이정도면 괜찮아. 이제 테스트 코드를 짜야지' 이 정도 시점이 되면
테스트 코드의 효용성이 많이 떨어집니다. 그래서 테스트 코드를 먼저 작성하는게 좋다고 봅니다.

TDD를 하면 설계가 어느정도 해결되는가? 어느정도 해결되는것은 맞지만 그런 목적의 TDD를
하기 보다는 설계 작업 자체에 공을 들이는게 비용면에서 더 낫지 않나 하는 생각도 해봅니다.

2012/3/28 Jaepyoung Kim <jaepyo...@gmail.com>

--
Blog: http://pragmaticstory.com
Twiter: @k16wire

[임병인(포데브)]

> [김창준]님의 요약:
> - 테스트를 나중에 하냐, 먼저 하냐만으로 TDD다 아니다를 이야기할 수 없다.
> - TDD에서 Test라는 말이 있긴 하지만, 이것은 엄밀하게 말해 엉성한 테스트다. 자칫하면 과신할 수 있다.
> - TDD를 좀 더 넓게 볼 수 있다.
> - 테스트 자체도 DDD를 적용해서, 테스트 작성이 고통스럽지 않아야 한다.
> - 테스트 결과를 예측하기 힘들 때에도 테스트 작성은 가능하다.
> - TDD에 너무 얽매이지 않는 것이 필요하다. 그러면서 나의 상황파악능력, 의도적 수련이 어떻게 되고 있는지 확인해야 한다.

의미있는 요약입니다. 그리고...

> 참고로 켄트 벡은 XP 2.0(Extreme Programming Explained 2판)에서 TDD 대신 TFP(Test First
> Programming, 역서에서는 "테스트 우선 프로그래밍")라는 말을 써서 의도적으로 테스트가 앞에 와야 함을 강조하고 있습니다.
> 저는 TFP와 짝을 이뤄, 반복적으로 코딩 후 자동화된 테스트를 만드는 것을 TLP(Test Last Programming)이라고 하고
> 있고, 이미 TLP의 효용에 대해 여러번 이야기한 적이 있습니다(http://agile.egloos.com/5299932 참고).

TFP와 TLP에 대한 설명이 인상깊습니다.

On 3월28일, 오후2시58분, June Kim (김창준) <junea...@gmail.com> wrote:
> 2012/3/28 임병인(포데브) <brianlim.next...@gmail.com>

> - 테스트를 나중에 하냐, 먼저 하냐만으로 TDD다 아니다를 이야기할 수 없다.
> - TDD에서 Test라는 말이 있긴 하지만, 이것은 엄밀하게 말해 엉성한 테스트다. 자칫하면 과신할 수 있다.
> - TDD를 좀 더 넓게 볼 수 있다.
> - 테스트 자체도 DDD를 적용해서, 테스트 작성이 고통스럽지 않아야 한다.
> - 테스트 결과를 예측하기 힘들 때에도 테스트 작성은 가능하다.
> - TDD에 너무 얽매이지 않는 것이 필요하다. 그러면서 나의 상황파악능력, 의도적 수련이 어떻게 되고 있는지 확인해야 한다.

[Youngrok Pak]

첨언하자면, "주먹이 운다" 같은 프로그램에 나온 길거리 싸움 경험 많은, 자칭 도시별 짱인 사람들이 이종격투기 프로 선수와의 1분 경기에서 왜 초등학생처럼 무력해 보이는지 생각해 봐야 합니다

저는 창준님의 이 말을 좀더 음미할 필요가 있다고 봅니다. 비단 이종격투기 뿐 아니라, 다른 스포츠, 바둑 등에서도 흔하게 보이는 현상입니다. 바둑 같은 경우도 10년 아마 고단자가 경험을 바탕으로 온갖 변칙을 다 구사하지만 기원에서 정식으로 배운 1년도 안된 정석 밖에 모르는 10살 짜리 꼬마에게 처참하게 지곤 하죠. 

"태권도의 품세를 익히는것은 중요하지만 실전에선 품세대로 하지않는다."

병인님이 위와 같은 말씀을 하셨는데, 아마도 바둑에서 "정석은 배우고 잊어버려라"라는 말과 통하는 말일 것입니다. 그런데, 사실 저 말에서 중요한 부분은 '잊어버려라'가 아니고 '정석을 배우고'입니다. 바둑에서 정석을 배우지만 실전에서 정석을 그대로 쓰지 않는 이유는 주변 상황이 바뀌기 때문인데, 상황은 바뀌지만 정석의 수순과 프로 기사의 실전 수순에서 차용하는 원리는 똑같습니다. 프로 기사들은 '정석을 배우고' 써먹어보는 과정에서 사실은 원리를 학습하는 것이죠.

그래서, TDD가 효과적인 이유, 그 기본 원리들을 잘 이해하고 있다면 TDD라는 형태를 빌지 않더라도 자유자재로 그 원리를 충족시킬 방법을 찾아낼 수 있습니다. 그런 면에서 테스트를 꼭 먼저 만들어야 하는 건 아니라는 말이 틀린 말은 아니지요.

하지만 여기에는 두 가지 문제가 있습니다. 하나는 그 전제, "기본 원리를 잘 이해하고 있다면"을 충족시키기가 어렵다는 것입니다. 원리를 잘 모르는 상태에서 기본기를 벗어난 수순을 밟게 되면 대개는 플러스가 되기보다는 마이너스가 됩니다. 제가 봐온 TDD 사례 중에도 실질적으로 TDD를 플러스가 되게 활용하는 경우는 많지 않았습니다. TDD를 적용해서 프로젝트 기간이 늘어났다고 호소하는 경우도 흔하구요. 이런 건 모두 The Goal을 달성하는데 실패한 케이스죠.

또 하나는, TDD를 변형해서 활용하는 방법이 여러 가지가 있겠지만, 그 중에서 "테스트를 나중에 작성하는" 변형 형태는 TDD의 원리를 벗어나 있는 경우가 많다는 것입니다. 대개 이런 형태는 상황에 맞게 TDD를 변형했다기보다, 테스트를 먼저 작성하기 어려워서 나중에 작성한 것이거든요. 바둑을 예를 든다면, 정석에서 벗어나서 두는데, 그 이유가 주위 배석이 달라졌기 때문이 아니라 적절한 수를 찾아내는 수읽기에 실패했기 때문에 다른 수순을 밟은 것이죠. 이런 경우는 좋은 결과가 나오기 어렵습니다.

TDD는 초보자가 즉각적인 성과를 내기에 아주 좋은 기술이기도 한 반면, 적용 난이도 최고로 분류될 만큼 어려운 기술이기도 합니다. 기본 프레임 자체는 쉽기 때문에 쉽게 따라해볼 수 있고, 쉬운 문제에서는 기대 이상의 성과를 낼 수 있지만, 프로젝트에는 그런 초보 수준의 TDD로 풀 수 없는 문제들이 있기 마련이죠. 그래서 TDD가 쉬운 문제에선 별 한 개 짜리 난이도인 반면, 조금만 어려워지면 갑자기 별 다섯 개짜리가 되버립니다. 그러다보면 테스트를 나중에 붙이는 변형을 취하기 쉬운데, 그렇게 되는 순간 왜 붙었는지 모르는 테스트들이 늘어나면서 테스트가 오히려 레거시로 작용하는 경우가 많죠. 특히 그런 테스트들이 중복 제거마저 잘 안되어 있다면 실제 코드 이상으로 강력한 레거시가 됩니다.

저는 그래서, TDD를 하기 어려운 문제는 끝까지 Test First로 파고들 게 아니라면 차라리 해당 문제를 깊이 이해할 때까지 TDD를 하지 말라고 권합니다. TDD를 하지 않고 개발하되, 계속 TDD를 염두에 두다보면 TDD로 풀지 못했던 문제가 어느 순간 방법이 보입니다. 그러면 그 문제는 그 다음부터 TDD로 푸는 거죠.

여튼, 꼭 테스트를 먼저 작성해야 TDD의 효과를 얻을 수 있는 것은 아니고, 심지어 테스트 전혀 만들지 않고도 TDD의 효과를 얻을 수도 있지만, TDD의 여러 가지 변형 중 "테스트 나중에 붙이기"만큼은 약간이나마 도움이 되기보다, 해가 되는 경우가 더 흔하게 보입니다. 그래서, 저는 병인님이 문제 제기는 아주 적절하게 해주셨다고 생각하지만, 그 해법에는 동의하지 않는 것이구요.

[이광운]

저도 평소 생각을 2개 공유해봅니다.

1. TDD, Test First
- 아이들에게 밖에 나갔다 돌아오면 하는 말이 있습니다. "XX야 손,발 씻어요"
- 이 얘기는 밖에 잠깐 나갔든 멀리 나갔든 "습관"을 길들이기 위해서 입니다.
- Test First도 저는 그런 "습관"을 길들이는 것으로 생각하고 있습니다.
- 그리고 그것이 몸에 밴 뒤에 융통성이 발휘되겠죠.

2. Test 맹신
- 제가 지금 다니는 회사 팀장으로 오기전 전임 팀장이 서버 사이드 개발이었고 그 밑에 대리가 클라이언트였죠.
- 전임 팀장은 서버 사이드에 충실히(?) Test를 만들었습니다.
- 인수테스트시에 특정 기능이 동작을 제대로 안되었는데
- 그때 서버사이드 개발쪽의 태도는  "테스트는 잘 도는데", "그럴리가 없는데", 스스로에게는 절대 문제가 없다는 입장을 취하고 결국 클라이언트 개발자가 패킷 모두 캡춰하고 보여줘야 자신의 테스트 케이스가 잘못된 걸 인정하더군요.
- 패킷까지 캡춰해서 들이밀 정도면 그 분위기는 짐작하시리라 생각됩니다.
- 결국 그런 상황이 여러번 이어지고 상급자 권위는 바닥으로 떨어졌습니다. (결국 몇 개월 뒤 퇴사)
- 전 이 상황을 전해듣고 제 스스로도 테스트를 맹신하지 말아야지 다짐했습니다.

흥미진진해집니다.