TDD 적용하기 질문

[피터518]

안녕하세요. 얼마전에 TDD관련 질문을 올렸었던 이원우입니다. ^^

프로젝트에 TDD를 적용함에 있어 질문이 있는데요..

이미 TDD없이 개발된 프로젝트에 유지보수를 하면서 TDD를 적용할려면

어떤식으로 해야할지 모르겠어서...질문을 올립니다.

단순한 기능추가는 TDD를 사용하면 되겠는데

이미 구현되어 있는 클래스에 대한 TDD는 어떤식으로 진행해야할가요?

이미 구현되어 있는 클래스에 대한 TDD는 할 수 없을까요?

이미 클래스가 구현되어 있기때문에 TDD를 적용하는것 자체가 모순인가하는 생각도 들고요.

[아샬]

이미 구현된 코드에 테스트 코드만 붙인다면 TDD란 말을 굳이 사용할 필요는 없을 것 같습니다. (test가 driven하는
development가 아니므로...)

하지만 대부분 테스트 코드를 붙이기 어렵기 때문에 TDD에 준하는 노력이 필요하다고 봅니다.

TDD를 하냐 안 하냐에 무관하게 어떤 식으로든 테스트 코드를 갖추는 건 불가능한 일이 아니며, 매우 중요하다고 생각합니다.

2010년 7월 8일 오전 9:35, 피터518 <wonw...@gmail.com>님의 말:

> --
> Google 그룹스 'Agile Beginners' Q&A' 그룹에 가입했으므로 본 메일이 전송되었습니다.
> 이 그룹에 게시하려면 ab...@googlegroups.com(으)로 이메일을 보내세요.
> 그룹에서 탈퇴하려면 abqna+un...@googlegroups.com로 이메일을 보내주세요.
> 더 많은 옵션을 보려면 http://groups.google.com/group/abqna?hl=ko에서 그룹을 방문하세요.
>
>

[June Kim (김창준)]

2010/7/8 피터518 <wonw...@gmail.com>

클래스 단위로 TDD를 붙이는 것도 한 가지 전략입니다.

다음과 같은 방법도 있습니다.

• 자주 고치면서 결함 위험도가 높은 사용자 스토리 중에서 가장 variation이 적은, 단순한 사용예를 고릅니다.
• 해당 부분에 대해 가장 이해도가 높은 사람을 찾습니다.
• 그 사람에게 묻습니다. "가장 간단한 예가 뭔가요? 간략하게 설명해주실 수 있나요?"/"그게 정상적으로 된다는 건 뭘보고 아나요?"
• 그 사람의 "설명"을 기록합니다.
• 그 설명을 테스트로 만듭니다. 그 사람이 설명할 때 썼던 어휘를 되도록 그대로 사용하고, 그 사람이 쓰지 않은 어휘는 되도록 쓰지 않습니다.
• 테스트가 실패할 겁니다.
• 이 테스트가 최대한 빨리 초록색이 되게 만듭니다.
  
• 이 테스트가 초록색인 상태에서, 코드를 주무르고, helper object(아마도 SUT이나 Test code 모두에 필요할 겁니다)를 추가하면서 리팩토링합니다. 맨 첫 단계에 end-to-end의 성근 회귀 테스트를 두어개 추가하지 않고 시작한 경우라면, 파괴적 리팩토링(예컨대 메소드 추가는 하되 변경이나 삭제는 없도록)은 되도록 하지 않습니다.
• 위 테스트를 리팩토링 해나가는 과정 중 새로운 helper object의 추가시에는 TDD를 적용합니다.
  

[June Kim (김창준)]

이 방법을 사용하게 되면, Test Code의 helper object로 만든 것들이 나중에 오히려 SUT의 유용한 객체가 되는 경우가 흔합니다. 그리고 그 객체는 더 나아가 Domain Model을 단순화하고 우아하게 만들기도 합니다. 도메인 전문가가 놀라기도 하죠.

2010/7/9 June Kim (김창준) <june...@gmail.com>

[Albert Park]

안녕하세요. 박규진입니다. 

연습문제를 푼다는 생각으로 최대한 qna에 하나하나 답글을 달아보고 있습니다.

물론 연습문제는 모두가 함께 푸는 것이니, 많은 추가의견 부탁드려요~ ^^

비어있는 시간이 충분히 있다는 가정하에 하는 것은 매우 좋다고 생각합니다.

이미 테스트 코드를 붙이는 것은 아마도 TDD와는 반대로 

큰 모듈에 관한 거시적인 테스트 부터 시작해서 점점 작은 모듈로 

내려가는 Top - Down 형태로 테스트를 만들어 가는  것이 좋을 것 같습니다.

이 경우 

1. 테스트를 만들다가 중간에 멈추더라도, 일단은 전체적인 테스트 범위는 나오기 때문에 조금더 믿을만한 테스트 케이스가 될 것 같습니다.

2. 세부적인 테스트 케이스 부터 하나하나 짜다가는 오히려 점점 세분화되어 전체적인 테스트 범위를 완성하는 것은 불가능 할 것 같습니다. 

마치 "1단원에만 밑줄 빽빽이 그어져 있는 수학의 정석"처럼 시작 부분에만 세세하게 치우쳐지는 불균형한 커버리지가 될 것 같습니다.

하지만 현실에서는 언제나 시간은 충분하지 않을 것 입니다.

저번에도 비슷한 연습문제를 푼 기억이 있는데요. ^^;;

지금부터 구현/ 리팩토링/ 수정 되는 부분에 대해서만 테스트를 구현하는 방법이 있습니다.

1. 이 경우 끝없는 테스트 추가의 유혹에서 벗어 날 수 있습니다.

사실 이미 있는 코드에 대한 테스트를 만들 경우, 테스트의 "범위"와 "밀도"를 점점 더하다 보면 정말 끝이 없을 것 같습니다.

2. 사실 TDD를 하면서 자신이 구현하지 않은 OS 레이어의 함수에 대한 테스트 케이스까지 짜넣는 사람은 없습니다.

(시스템 프로그램을 직접 짜는 경우는 제외겠죠. -_-;;;) 

이미 구현된 코드는 그냥 기반 시스템 취급을 하고 이제부터 짤 부분에 대해서만 테스트를 짜는 것이 TDD가 아닐까 합니다. 물론 기존 구현된 코드에서 버그가 검출 되거나 리팩토링이 필요해진다면, "수정"해야 하니, 

수정부분을 분리하며 TDD기반으로 다시 짜면 되겠죠.

감사합니다.

2010년 7월 9일 오전 1:08, 아샬 <ahas...@gmail.com>님의 말:

--
박규진 혹은 Albert Q. Park
qjinp.Queue'z.6153124.큐즈.상파.

항상 오늘을 사는 마음으로 앞도 뒤도 없이 차분히 걸어간다.
개별적 상황을 이해하고 서로 다름을 인정하기 위해 노력하며
새로운 발상과 개성을 존경한다.

[HarryPark]

관련 내용을 다룬 책 중에서 가장 유명한 책인 "Working effectively with Legacy Code"를 읽어보시
면 많은 도움이 되리라 생각합니다.
번역판인 "레거시 코드 활용 전략"을 읽으셔도 되구요.
(근데 번역상태가 별로여서 출판사에서 재번역작업중이라는 얘기도 들은 적이 있습니다.)

규진님 말씀대로 거시적인 테스트를 만드는것부터 시작한다는 의견에 동의하구요.

저는 5년정도된 코드베이스에 테스트케이스를 추가하는 작업을 하였는데,
인수테스트에 해당하는 거시적인 테스트를 만들어 가면서 작업을 했었습니다.
변경해야 하는 부분이 발생하면 그 부분이 포함된 전체 시나리오에 대해서 테스트케이스를 작성하여,
실패하는지 확인하고, 해당부분을 수정하여 테스트케이스가 성공하는지 확인하는 방식으로 진행했구요.
변경할 때마다 반드시 테스트케이스를 만들도록 진행하니 시간은 좀 걸리지만 지금은 그동안 투자한 시간이
아깝지 않을 정도로 효과를 보고 있습니다.

어려움도 많겠지만 꾸준히 진행하시면 좋은 효과가 있을겁니다.^^

[피터518]

답변해주신 HarryPark님, AlbertPark님, 창준님 감사합니다. ^^
어떻게 적용해봐야할지 감이 안왔는데
TDD첫걸음을 시작할 수 있을것 같아요.