Visual Studio 2010 공식 팀 블로그 @vsts2010

단위 테스트를 어떻게 해야 잘 하나…?

단위 테스트를 어떻게 해야 잘 하는지는 사실 논란의 여지가 굉장히 많습니다. 왜냐하면

• TDD를 해본사람 vs 안해본사람
• TDD가 능숙한 사람 vs 능숙하지 않은 사람
• 개발툴에서 TDD를 제공하는 환경 vs 제공하지 않는 환경
• 테스트 지식이 있는 사람 vs 없는 사람
• …

어쨌든 목표는 동일합니다. 작성된 코드에 대한 테스트를 수행하는 것이죠. 일반적으로 테스트의 목표에 따라 테스트 방법이 달라질 수 있지만, 흔히 단위 테스트는 기능 범위에 한하여 테스트 코드를 작성하는 방법입니다. 어떻게 코드가 변경이 되든, 어떤 데이터소스 이든지 간에 성공해야 할 테스트는 반드시 성공하고, 실패해야 할 테스트는 반드시 실패해야만 기능이 올바르게 동작한다는 것을 최소한으로 보장할 수 있다는 것입니다.

무엇이 단위 테스트를 어렵게 하나?

단위 테스트는 어떻게든 하는 것은 매우 쉽지만, 어떻게 해야 잘 할 수 있고, 시간을 단축하는 방법도 매우 중요합니다. 맹목적인 단위 테스트는 테스트의 목표를 상실하게 만들 수 있고, 의미 없는 더미(Dummy) 테스트 코드가 되기가 매우 쉽습니다. 그리고 더미(Dummy) 단위 테스트 코드를 양산하는 방법도 매우 쉽습니다.

• 테스트에 대한 지식이 없는 경우
• 처음부터 목적/목표가 없는 테스트 코드 작성
• 테스트 방향이 잘못 설정된 경우
• 단위 테스트 관리 방안이 없는 경우
• 처음부터 잘못된 디자인이나 구현 도중 발생하는 디자인 결함

그리고 일반적으로 인간의 생각의 흐름은 매우 순차적입니다. 복잡한 생각 등을 결국은 순차적으로 나열을 하게 되지요. 그 대표적인 것이 자신의 머리 속에만 존재하던 사건을 도식화하는 것이 바로 육하원칙(5W1H) 입니다. 이런 육하원칙과 같이 테스트 대상을 명확하게 테스트 코드로 구현하는 것도 매우 중요한 부분입니다.

• Who - 누가
• When - 언제
• Where - 어디서
• What - 무엇을
• Why - 왜
• How - 어떻게

그리고 마지막으로 단위 테스트를 하는 것 중 "무엇을 테스트해야 하나?" 입니다. 테스트 대상을 어떻게 쪼개어 테스트를 해야 가장 생산적이고, 중복되지 않는 테스트를 작성하는가는 즉시 테스트의 관리 비용과도 영향을 미치는 중요한 부분이기도 합니다. 즉, 테스트 코드가 중복이 되면, 관리되는 테스트 코드의 양이 늘어나고, 그 테스트 결과가 반드시 성공/실패해야 함에도 그렇지 않게 될 수 도 있습니다.

흔히 열광하는 TDD(Test-Driven Development) 도 마찬가지입니다. 이론적으로 그 용이성은 필자도 인정하지만, 사실은 매우 실용적이지도 않고, 효과적이지도 않습니다. 더불어 위의 나열한 테스트 지식, 목표, 테스트 방향, 관리 방안, 디자인 측면에서도 명확하지 않는다면 쥐약과도 다름이 없습니다. 즉, 테스트라는 것에 집중되어 그 목표, 방향을 제시하기 힘들며, 객체지향적인 코드를 만들기도 어려우며, 실제로 지저분한 코드를 만들기 매우 쉬운 방법이기도 합니다.

즉, 인간의 생각은 매우 복잡한데, 순차적인 도식화 작업을 하지 않은 채로 순차화를 시키려 하니 테스트 코드의 품질과 소스 코드의 품질은 기대 이하가 대부분이었습니다.

계약 기반의 테스트

최근에는 계약 기반(Contract-Based)의 아키텍처 또는 패턴의 개발이 매우 활발합니다. 코드적으로 추상화를 통해 매우 명확하며, 이런 추상화된 모형을 통해 완벽하게 모형의 인터페이스를 통해 시그너처를 구현해 나가는 방식입니다. 정확하게 계약 기반의 개발도 아니며, TDD, BDD(Behavior-Driven Development)도 아닌 그 중간적인 형태를 취하는 방법입니다.

계약 기반(Contract-Based)의 개발 방식은 이전에 자주 세미나에 언급을 하였습니다. 자동차보험의 경우 계약서와 아래와 같은 계약 명세가 존재 합니다. 이 명세가 바로 인터페이스의 모형과 시그너처에 해당한다고 봐도 무방합니다.

아래는 자동차보험의 계약 명세에 대한 상세적인 약관입니다. 이 약관은 계약 명세에 대해 자세하게 약관을 명시하고 있으며, 이것을 인터페이스의 구현이라고 보셔도 무방합니다.

즉, 인터페이스의 모형과 시그너처는 단순히 객체지향적인 인터페이스를 넘어, 계약(Contract)적인 관점의 신뢰를 이루기도 합니다. 바로 그 계약을 잘 설명했던 TechDays 2010 Spring 의 슬라이드를 몇 장 재활용해보면^^

계약 기반의 개발과 테스트의 장점

물론 이 계약 기반의 개발과 테스트의 장점이 없다면, 필자 또한 이렇게 침을 튀기며 얘기하지는 않을 겁니다. 이전에 얘기했듯이 테스트는 하면 할수록 어려워지고, 또한 관리하기도 무척 버거워집니다. 그 과정에 의지와 다르게 테스트의 목적과 목표가 소실되고, 테스트의 방향성을 상실하는 경우가 허다합니다. 그리고 잘못된 초기 디자인이 특히 돌이키기 힘든 어려움이 될 수 있습니다.

사실 어떤 기가 막힌 테스트 기법도 명세(인터페이스의 모형, 시그너처)가 변경이 되면 많은 노가다(?)를 감수해야 할 수 밖에 없습니다. 바로 리팩토링(Refactoring) 작업인데, 좀 더 나은 코드/디자인을 위한 것이긴 하지만, 너무 많은 리소스나 비용이 필요하다면 이 리팩토링 작업이 전혀 즐겁지 않는 작업이 되기도 합니다.

하지만 절대 변하지 않는 진리 중 하나는, 쪼개진 것을 합치는 것은 쉬워도, 합쳐놓은 것을 쪼개기는 매우 어렵기 때문입니다.

각설하고, 계약 기반 테스트가 TDD보다 좀더 효과적인 이유는

• 허술하게 하는 TDD는 테스트 목적/목표가 불명확한데 테스트 코드를 먼저 짠다?
• 보험의 약관을 가지고 명세를 만들어 간다? 무지 어렵겠는걸…?
• 디자인 목표가 없는 추상화가 과연 올바른 추상화인가…?
• 코드는 생각을 먼저 하고 짜는 것이 방어적/효과적/객체지향적인데, 타이핑 먼저…?

위의 나열한 몇 가지 이유만으로, 필자는 TDD를 싫어하는 이유이기도 하지만 특히 싫은 이유는 리팩토링부터 시작하는 코드는 죽어라 리팩토링으로 끝나기 마련입니다. (리팩토링을 반드시 그 자체의 의미에 두고 하는 얘기는 아닙니다) 뒤돌아서면 내심 찜찜한 기분도 들고, 좀 더 완벽함에 가깝게 디자인하려 하지 않은 것이 어찌 완벽함에 가까워지겠습니까.

물론 어떤 테스트 기법이든지 "경우에 따라 잘 맞을 때가 있고 안 맞을 때"가 있습니다. 다만, 이런 TDD 기법 하나로 찬양하다시피 어떠한 올바른 방향을 제시하지 않는 것은 매우 위험한 발상이기도 합니다. 필자는 TDD 의 울타리에서 벗어나야만 올바른 TDD 를 할 수 있다고 생각을 하며 이만^^

애자일에 대한 고찰에 앞서 먼저 '정말 TDD 가 필요한가?' 에 대해 이야기 부터 시작해봅니다.

애자일에 대한 고찰

애자일 프로그래밍이 도마에 오르면서 단연 단위 테스트(Unit Test)와 TDD(Test Driven Development) 를 빼놓을 수 없습니다. 단위 테스트와 TDD는 상호 공생 관계에 놓이면서, 둘 중 어느하나 포기하기 쉽지 않습니다. 왜냐하면 TDD에 대한 이상론자들은 TDD의 중요성을 매우 높이 강조하고 있기 때문입니다.

필자는 이에 대해 정말 개발에 TDD가 얼마나 좋고 효과가 좋은지 사실 산술적으로 검증할 수는 없다고 생각합니다. 좋은 것이 있는 많큼 잃는 것도 있을테니까요.

TDD 를 해야한다는 관점

일반적으로 코드를 작성한 후에 그 기능을 테스트하는 코드를 작성하는 것을 단위 테스트라고 합니다. 단위 테스트를 작성함으로써 결함없는 소프트웨어를 만들기 위한 지속적인 통합(CI-Continuous Integration) 라는 관점에서 상당히 효과적인 방법입니다.

여기에서 TDD 는 단위 테스트를 작성하는 단계의 순서를 기존의 Last 에서 First 로 바꾸면서, 단위 테스트 코드를 먼저 작성하도록 하는 방법입니다. 처음 오류가 날 수 밖에 없는 코드를 테스트하면서 Red, Green, Refactor 단계로 옮겨가도록 하는 기법입니다.

사실 이런 저런 TDD 의 효과중에 단연, 코드가 매우 견고해진다는 큰 장점이 있습니다.    

처음부터 기능을 구현하는 코드를 작성하게 된다면, 클래스와 메서드를 잘 분리한다고 하더라도 한 클래스나 메서드는 생각지도 않게 기능의 크기가 커질 수 밖에 없습니다. 왜냐하면 코드 작성자는 코드를 만드는 목적이 기능이 정상적으로 작동해야 한다는 전제하에 코드를 만들기 때문에 오류 없는 코드가 목적이기 때문입니다.

또 한가지 TDD를 하지 않는다면 코드의 리팩토링을 코드가 완료된 이후에만 가능하다는 것입니다. 지속적으로 이런 문제는 소프트웨어의 디자인이 바뀌거나 오류가 발생하지 않을 경우 굳이 리팩토링을 하지 않게 되죠.

결국 어떤 이유에서든지 좋은 코드를 만들기 위해서는 TDD가 매우 좋은 기법이 될 수 있습니다. 쉽게 Database 를 예로 들자면, 초기에 테이블을 정규화할 것인지, 나중에 문제가 생길 경우 정규화를 할 것인지의 고민과 유사하기도 합니다. 하지만 절대 변하지 않는 진리는, 처음부터 갈귀갈귀 정규화를 한 것을 합치는 것은 쉬워도, 통짜를 분리하는 것은 사실 엄청난 리스크가 됩니다.

TDD 를 하지 말아야한다는 관점

개인적으로 필자는 이 부류에 속하기도 합니다. 누구든 TDD를 알게 되면 그것이 가지는 이상적인 효과를 이해할 수 있습니다. 하지만 살짝 TDD에 발가락을 담구어보면 금방 TDD에 대해 의심을 하게 됩니다. 바로 TDD를 해보면 너무 어렵다는 것입니다.

첫번째로 Red, Green, 그리고 최종적으로 Refactor 단계로 가는 과정이 오래 걸리고 어렵습니다. TDD코드를 만들기 시작하는 순간부터 리팩토링의 시작이며, 길지 않은 코드조차 굉장히 버겁다는 것을 알 수 있죠. 정말 지루하고도 기계적인 과정입니다.

두번째는 이미 언급했다시피 지루하고도 기계적인 과정입니다. 즉 TDD기법으로 생상되는 코드는 기존에 코드를 만들고 테스트하는 예상 시간이 +a 가 됩니다. 코드의 양에 비례하여, 'stub(코드의 양) * alpha(가중치) = TDD 수행시간' 이라는 대략적인 예측 소요 시간이 걸릴 것입니다.

TDD의 시작은 곧 리팩토링의 연속입니다. 아무리 개발 도구가 좋아진다고 하더라도 사람이 하던 리팩토링을 대신해줄 수는 없을 것입니다. 즉, TDD기법을 도입하기 위해서 기존 방식의 산술적인 계산법으로 더 이상 기간과 공수를 예측할 수 없습니다. 분명 시간과 비용이 터무니없이 증가할 것입니다.

아마도 우리나라에서는 TDD를 조직내에서 개발 방법으로 채택하는 곳은 없다고 봅니다. 우리나라에서는 소프트웨어의 생산 기간을 어떻게 줄일까에 집중하고 있기 때문에, TDD는 팀과 조직의 goal 에 방해 요소만 될 뿐입니다. 효용성 측면에서 TDD를 본다면 그저 빛 좋은 개살구로 보이기 쉽기 때문입니다.

애자일을 명목으로 스스로 족쇄를 차고있는 우리 조직

애자일이라는 이름과 이상적인 가이드를 이행하려는 조직에서 특히 불화음이 많을 것입니다. 그리고 그들은 애자일을 해 본 결과 애자일은 왜 실패하냐는 물음을 던집니다. 사실 애자일이 가지는 그 사상은 굉장히 높이 살만 합니다. 기존의 폐쇄적인 조직을 개방하려는 의지를 보인다는 것으로 시작하여 팀간의 커뮤니케이션을 향상시키도록 합니다.

그런데 애자일을 도입하려는 사람들은 큰 함정에 빠집니다. 팀을 위한다는 명목으로 너무 많은 것을 팀에게 강요합니다. 자신이 바라보기엔 좋은 기법들이 많고 팀에게 전파하려고 노력하겠지만, 팀은 이미 기존에도 잘 되고 있는 부분을 왜 뜯어고치려는지 이해할 수 없기 때문이죠. 팀에게 변화라는 명목으로 팀원들의 공감을 얻지 못한채로 강요를 시작하게 됩니다.

사실 애자일한 팀과 애자일한 프로그래밍을 위해 애자일은 아무것고 강요하지 않습니다. 그런데 누군가의 손에 애자일이 쥐어지면 은근히 강요로 변질되는 경우가 대부분입니다.

애자일 중에, 특히 XP(eXtreme Programming) 는 우리나라 실정이 전혀 반영되지 않았습니다. XP 의 여러가지 기법 중에 특히 코드 리뷰 와 짝 프로그래밍이 대표적이죠. 짝 프로그래밍은 짝이 되어 서로의 생각과 노하우를 전수해 주는 기법이지만, 필자로써는 '글쎄…'

필자는 오히려 짝 프로그래밍을 함으로써 개인 업무 시간을 너무 할애당한다는 생각이 듭니다. 필자가 메신저의 채팅보다 이메일을 좋아하는 이유도 여기에 있습니다. 업무 진행에 탄력을 받다가도 채팅으로 내 생각의 컨텍스트가 강제로 전환됩니다. 생각이 정리되지 않은 상대편이 타자를 치고있는 것을 멍하니 바라만 봅니다. 기술적인 것을 물어볼땐 답을 알려줘도 채팅이라는 특성상 한번에 한줄의 글로 모든 것을 표현하기가 힘듭니다. 만약 이메일이었다면 보낸 사람도 생각을 정리해서 보냈을테고, 또한 내가 보고싶을 때 보고, 명쾌한 MSDN 링크와 곁들여 오히려 짧은 시간에 높은 성과를 낼 수 있을텐데요...

결국 짝 프로그래밍은 그것을 성취한 후의 성과가 소비된 리소스에 비해 턱없이 낮으며, 짝 프로그래밍의 특성상 지속성을 유지하기에 한계가 있습니다.

또, 코드 리뷰를 진행하기 위해 다양한 기법들과 절차를 선보입니다. Self Review, Pair Review, Team Review 등 전혀 현실을 고려하지 않고 단지 그 기법들에 대해서만 매달리는 사람들이 많습니다. 특히 코드 리뷰는 도구를 이용한 자동화를 하지 않을 경우 있으나 마나한 기법입니다. 장기적으로 코드 리뷰는 형식적일 수 밖에 없습니다.

더 중요한 것은 코드 리뷰 기법이 아니라, 프로세스적으로 이것을 통제하여 코드 리뷰 책임자를 두는 것이 효과적일 수 있습니다. 보안이나 성능 등에 관련하여 코드 리뷰의 책임을 위임하고, 보안이나 성능 문제 발생시에 책임을 물을 수 있도록 체계화된 프로세스 말입니다.

사실 이런 면에서 기존의 애자일인 XP(eXtreme Programming) 이나 스크럼(Scrum) 보다 MSF(Microsoft Solution Framework) 가 기존 애자일 방법론을 현실적이고 수행가능하도록 체계화시킨 프로세스이기도 합니다.

입장이 서로 다른 애자일

대부분 현장에서 개발하시는 분들은 내 옆의 동료나 우리 팀보다 자기 개인이 더 중요할 것입니다. 개인 업무 성과가 팀과 조직이 나를 판단하는 기준이 대부분의 경우이기 때문입니다. 또 어떤 경우는 개발자의 특성상 발언권이 없는 경우도 있을 것입니다.

이에 반해 팀의 관리자의 평가는 자신이 관리하는 팀 전체의 성과가 조직이 관리자를 판단할 것입니다. 팀 프로젝트나 팀의 업무 성과가 낮다는 것은 관리자의 능력과 비례하기도 합니다.

결과적으로 애자일이라는 공통 분모로 애자일의 목표를 이루고자하는 시각이 전혀 다르다는 것이죠. 서투른 애자일은 팀원의 불만만 증가할 뿐, 팀원과 공감대를 이루기 힘듭니다. 관리자의 입장에서는 팀원간의 커뮤니케이션을 높이고 팀원 스스로 변화하길 기대하고 이것이 소리없는 강요가 될 수 있습니다.

애자일을 성공시키기 위해

앞서 이야기한 바와 같이 애자일이라는 목표와 사상은 굉장히 좋습니다. 그것이 팀과 조직뿐만 아니라, 개인, 가족, 단체, 사회, 국가적으로 비유해도 좋은 모델이 될 것입니다. 하지만 애자일, 특히 XP 가 이루는 그 구성 요소들은 조금은 허무맹랑한 것들이 많습니다. TDD나 짝 프로그래밍, 코드 리뷰 등 현실성이 부족한 것들을 이행하기를 권장합니다. 적어도 우리나라에서는 그것을 이행하기 위한 주변 여건이 좋지만은 않지요.

예전 트로이 목마라는 전쟁 이야기에서 나오듯이, 적진에게 해를 가하기 위해 트로이 목마를 적진에게 가져다 놓았습니다. 적진은 트로이 목마를 보며 마치 신이 주신 선물로 생각하겠지만 정작 트로이 목마는 적군에게 해가 되는 무시무시함을 가졌습니다.

과학에서 모든 물체는 현재 상태를 유지하려는 힘, 관성을 가지고 있듯이 우리의 팀과 조직도 마찬가지 입니다. 애자일도 마찬가지로, 그것이 좋아보인다고 자신의 팀과 조직에 구역구역 쑤셔넣다보면 상태를 유지하려는 관성을 가진 구성원과 바로 맞닿을 수 있습니다. (물론 애자일이 해를 가한다는 의미는 아닙니다)

애자일이 추구하는 여러 구성 요소는 짧은 반복으로 결과물의 품질을 높이고 결함을 줄이고자 합니다. 애자일의 대부분의 구성 요소는 짧은 반복으로 인한 높은 위험성을 줄이기 위한 보조적인 수단이라는 것입니다. 예를 들면, 스크럼(Scrum) 을 도입한다고 해서 대시보드와 붙이는 메모지를 준비하고, 매일 매일 스크림 미팅을 할 필요는 없습니다. 스크럼 미팅이라는 형식에 갇히는 순간부터 자멸의 길이라는것을 뒤늦게 깨닳게 될 것입니다. 즉 스크럼 미팅은 매일할 필요도 없으며 어떤 다른 모습으로 바뀔 수 있고, 동료와 담배를 피거나 커피를 먹으면서 알게 모르게 나타날 수도 있습니다. 어떤 경우는 상대편 알게 모르게 하는것이 자연스러운 참여에 도움이 되는 경우도 있지요.

결론적으로 팀과 조직, 구성원 개인의 차이를 인정하고, 팀과 조직의 문화를 최대한 존중하는 것이 성공하는 애자일이 되는 것입니다. 필자 또한 이것을 깨닿기까지 많은 시행 착오를 겪으며 애자일로 인한 물음표에 종지부를 찍을 수 있었습니다. 즉, 애자일로 스스로에게 족쇄를 차지 마십시오. 족쇄를 끊은 후에야 진정한 애자일이 당신의 곁에 있음을 느낄 수 있을 것입니다.

이번에 Moq.NET 3.0 버전이 릴리즈 되었습니다. Moq.NET 는 Mocking Object 를 통해 특정 테스트를 진행하고 훨씬 TDD 기반에 근접한 테스팅을 가능하게 합니다. 즉, Mocking Object 는 실제 클래스나 개발이 완료되지 않는 시점에서부터 테스트를 가능하도록 합니다.

그런데 필자는 Moq.NET 를 이해하는 과정에서 내가 알고 있던 것보다 더 깊은 배경이 있었다는 것을 알게 되었습니다. 예를 들어, TDD 외에 BDD 또한 애자일 개발 방법론에 포함된다는 사실과, 조금은 낯설은 BDD-행위 주도 개발을 직접 체험해 보는 과정에서 말입니다. ^^ 

왜 TDD (Test-Driven Development) ?

TDD 가 좋으면서 쓰지 않는 이유는 뭘까요? 일반적으로 완벽한 TDD 를 수행하는 과정은 매우 힘듭니다. TDD 에 대한 이론을 들었을때는 확 가슴에 와닿지만, 이것을 몸소 체험하는 과정에서 개발자의 인내력의 한계를 올려놨다 내려놨다 하는 극한을 체험하게 합니다^^; 그러므로 일반적인 TDD 사이클인 Red, Green, Refactor 는 사람을 금방 지치게 만들죠^^; 한 사이클을 마치기 위해서는 많은 시간이 투자되어야 한다는 겁니다.

[그림1] TDD Process

하지만 우리가 TDD 를 수행하는 목적은 이러한 과정에서 코드에 대한 신뢰도를 향상시키고 품질을 향상시키고자 하는 것입니다. 그렇기 때문에 하고자 하는 목적이 보다 나은 품질을 보장하기 위해서라면 TDD 가 필요하다는 것이 머릿속으로만 느낌이 팍팍 옵니다^^;

이제 슬슬 스스로에게 딜레마다 옵니다. 좋은 줄은 알지만 누군가 나에게 TDD 를 강요한다면 아마도 전 "Oh~ No!" 라고 할 것 같네요 -_-;

WhiteBox Testing & BlackBox Testing

Moq 를 이야기 하기도 전에 정말 딴소리를 많이 하네요. 일반적으로 테스팅은 크게 WhiteBox Testing 과 BlackBox Testing 으로 구분할 수 있습니다. 이 두 가지 테스팅의 차이는 좁은 범위에서 내부적인 프로세스를 아느냐 모르느냐의 차이고요, 넓은 범위에서는 테스트 레벨의 차이라고 보시면 됩니다.

다음의 그림을 보면 좀 더 이해가 쉬울 겁니다.

[그림2] BlackBox Test 와 WhiteBox Test

즉 BlackBox Test 와 WhiteBox 테스트는 그 목표의 설정이 다르게 됩니다.

BlackBox Test 는 로그인 기능에 대해 요구사항이 있고, 그 기능이 반드시 가져야 할 스팩이 있을 것입니다. 요구사항을 통과하기 위해서는 로그인 기능의 스펙을 만족하면 되고, 실제 단위 테스트 등으로 그런 케이스를 통과를 하면 됩니다. 즉, 내부적으로 어떻게 동작하는지는 알아야 할 필요가 없으므로 수십/수백가지의 테스트 케이스를 통과하여 기능이 정상적으로 동작하는 것을 보장하기 위한 목표입니다.

WhiteBox Test 는 해당 기능에 대해 내부적인 구조를 기반으로 테스트를 진행하게 됩니다. 테스터는 이미 위의 로그인 기능이 내부적으로 어떤 프로세스로 진행되는지 알고 있으며, 예측 가능한 테스트 시나리오를 작성하여 테스트를 진행하게 됩니다. 이 테스트의 목적은 테스트 케이스를 통과하는 BlackBox Test 를 한 단계 뛰어넘어 잠재적인 오류까지 테스트를 통해 잡아내는 것이 목표입니다.
즉, 코드상의 Memory Leak 이나 SQL Injection, Stack Overflow 등 잠재적인 오류를 미리 찾는 경우도 있습니다. 이미 이런 기능은 Visual Studio 2005 이상부터 지원되는 정적 코드 분석(Static Code Analysis) 가 제공이 됩니다. 또, WhiteBox Test 는 코드 커버리지(Code Coverage) 의 수치를 높임으로써 테스트가 안된 코드의 양을 최소화 시키고, 궁극적으로 소프트웨어의 품질을 향상시키는데 있습니다.(Software QA)

안녕하세요. 이번에 Visual Studio Team System 2010 공식 블로그에 새롭게 참여하게 된 LazyDeveloper.Net의 kkongchi라고 합니다. Better Code 시리즈를 통해서 Code Analysis, Unit Test 등에 대한 포스팅을 해보도록 하겠습니다. 부족한 부분 많이 지적해 주시길 바랍니다.

TDD?

eXtreme Programming의 창시자 중 하나인 Kent Beck의 eXtreme Programming explained라는 책을 보면 Test를 작성하는 방법에 대해서 이렇게 기술하고 있습니다.

이런 eXtreme Programming의 Test-Before-Writing 전략을 개발 프로세스에 전면적으로 도입하는 것을 Test Driven Development, 즉 TDD라고 합니다. TDD에 관한 위키피디아 페이지에서 소개하는 TDD의 개발 사이클은 다음과 같습니다. “Red, Green, Refactor”라고 표현하기도 합니다.

다들 아시다시피, Visual Studio에서는 2005 버전에서부터 Team System의 일부로써 Testing Framework을 제공하고 지원해왔습니다. 그리고 드디어 이번 Visual Studio Team System 2010에서는 완벽하게 TDD의 개념이 Visual Studio Team System안으로 녹아 들어가게 된 것 같습니다. 바로 새롭게 추가된 기능 “Generate” 기능을 통해서, Test를 먼저 작성한 후에 그 Test로부터 코드를 자동으로 Generate해주는 기능이 추가된 것입니다.

TDD Development in VSTS 2010 by “Generate”

지난 11월에 나온 Visual Studio 2010 and .NET Framework 4.0 Training Kit의 Lab을 통해서 이 기능에 대해서 좀 더 자세히 알아보도록 하겠습니다.

당연히 먼저 테스트를 작성하는 것부터 시작합니다. 하지만, 아직 만들어지지 않은 클래스이기 때문에 아래 그림처럼 빨간색 물결 라인으로 경고가 뜹니다. 여기서 마우스 오른쪽 버튼을 눌러보면, 새로운 “Generate” 기능을 볼 수가 있습니다.

Generate class를 선택하면 같은 프로젝트에 Class가 추가됩니다. 하지만 Generate other..를 선택하면 아래와 같은 팝업 윈도우가 나옵니다. 클래스를 만들 수 있는 Wizard 개념이라고 보시면 되겠습니다.

이 Wizard를 통해서 클래스의 Access 한정자, Type, 그리고 파일을 만들 프로젝트까지 설정을 할 수가 있습니다. 이 과정을 통해서 우리는 완벽하게 Test로부터 시작해서 뼈대 코드를 만들어 낼 수가 있습니다. 아래 그림처럼 말이죠..

이제 이 자동으로 만들어진 뼈대 코드에 구현을 추가하게 되면 여러분들은 다음과 같이 Test를 통과했다는 기분 좋은 화면을 보실 수 있으실 것입니다.

위에서 보신 Demo Code의 시연은 http://channel9.msdn.com/shows/10-4/10-4-Episode-5-Code-Focused-in-Visual-Studio-2010/#Page=4 에서 Video로도 감상하실 수 있고, http://www.microsoft.com/downloads/details.aspx?FamilyID=752CB725-969B-4732-A383-ED5740F02E93&displaylang=en 에서 Lab Document와 소스 코드도 얻으실 수 있습니다.
 

지금까지 보신 것처럼 앞으로 출시될 VSTS 2010에서는 IDE 자체에서 완벽한 TDD 지원 기능이 통합되었습니다. TDD가 만능의 도구는 아닙니다. 하지만, 적어도 개발자가 자신의 코드에 대한 이해도가 통상적인 개발 방법보다는 훨씬 크고 깊을 것이라 기대합니다. 어설픈 문서보다는 잘 만들어진 테스트 코드들이 오히려 실제 구현 코드를 이해하는 데 더 도움이 되는 경우도 많습니다. Visual Studio Team System 2010은 효율적인 Test Driven Development를 가능하게 해주는 최고의 도구가 될 것 같습니다.

부족한 글 읽어주셔서 감사하고, 많은 의견 부탁 드립니다.