Visual Studio 2010 공식 팀 블로그

때는 바야흐로 2009년 7월이네요. Velocity 를 공부하면서 메모해 놓은 것을 이제서야 발견하여 포스팅을 하고 있습니다. ^^;

현재는 Windows Server AppFabric 이라는 이름으로 공개가 되고 있으며, 코드명은 바로 "Velocity" 라는 이름입니다. 현재 AppFabric Beta 1 까지 출시되었고 이제는 거의 모습을 찾아가고 있는 것 같습니다. 차후에 Velocity 의 현재 제품이름인 AppFabric 을 자세히 살펴보기로 하며, Velocity CTP 3 기준으로 설치와 사용 방법을 간단히 알아보고자 합니다.

Why Windows Server AppFabric (Codename "Velocity") ?

Velocity 는 분산 캐싱 프레임워크입니다. 우선 분산 캐싱이 왜 필요한지 이해가 필요합니다. 기존에는 캐싱이라고 함은 in-proc 캐싱을 의미했으며 즉 메모리 상에서 객체를 캐싱(Caching)하거나 풀링(Pooling)하기 위해 시스템의 리소스(Resource) 를 사용했습니다.

하지만 점차 엔터프라이즈 솔루션은 대규모, 대용량화 되어감에 따라 in-proc 캐싱은 시스템 리소스나 성능에 영향을 받게 되었습니다. 기존의 엔터프라이즈 솔루션은 데이터베이스의 대용량 아키텍처에 민감했고, 즉 데이터 중심의 아키텍처링을 할 수 밖에 없었습니다. 데이터의 정합성, 안정성, 성능은 기업에서 돈(Money) 와 직결되는 문제이기 때문이죠.

하지만 이미 데이터와 관련된 기술과 노하우는 이미 포화 상태이고, 엔터프라이즈 전체적인 아키텍처를 보았을때 단지 병목은 데이터에서만 존재하는 것이 아니었다는 것입니다. Middleware 나 Application Server 의 아키텍처링도 이미 포화 상태이고, 이것을 극복하기 위해서는 바로 캐싱(Caching) 이라는 기술이 필요했습니다.

위에서도 언급하였듯이 in-proc 캐싱은 굉장히 단순한 아키텍처입니다. 서버의 리소스가 받쳐 주느냐 그렇지 않느냐의 문제였고 in-proc 그리고 더 나아가 out-proc 를 이용하여 서버 자원을 최대한 활용하고자 합니다. 하지만 여기에서 또 문제가 발생합니다. 분산 out-proc 캐싱을 하자니 분산된 캐싱 데이터의 정합성을 어떻게 보장하느냐 입니다. 즉, out-proc 로 인해 캐싱은 중앙 집중화가 될 수 밖에 없으며 이것은 서버의 리소스에 의존하는 문제의 원점으로 돌아간다는 것이죠.

About Windows Server AppFabric (Codename "Velocity")

이러한 엔터프라이즈 환경의 서비스 확장에 대해서 고질적인 문제였던, 그리고 성능을 극대화 할 수 있는 캐싱이라는 기술을 어떻게 활용하느냐에 관심을 갖게 되었습니다. 현재 이런 문제를 해결할 수 있는 솔루션이 Windows Server AppFabric(Codename "Velocity") 입니다.

데이터의 정합성, 안정성, 성능은 기존의 아키텍처를 버리고 전용 Repository 를 통해 해결할 수 있습니다. 그것은 데이터베이스가 될 수 있고, 그 밖에 다른 Repository 가 될 수 도 있겠죠. 바로 이러한 컨셉은 캐싱을 어떤 분산 시스템간이라도 공유한다는 의미입니다. 이러한 캐싱을 클러스터링한다는 것은 흔히 Caching Dependency 를 해결할 수 있는 아주 좋은 해결 방법이기도 합니다. 어떤 로컬 시스템이건, 어떤 원격 시스템이건 캐싱 정책을 적용받게 되는 것입니다.

Install Windows Server AppFabric (Codename "Velocity")

아래는 필자는 게으름으로 Velocity CTP 3 기준으로 설치하는 방법입니다. (지금이라도 포스팅 하는걸 보면 대견스럽습니다만;;;)

기본적으로 캐싱 데이터는 데이터베이스를 사용합니다. 데이터베이스의 파일이 저장이 될 경로를 입력하거나 Storage 타입을 정하시면 됩니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

오랜만의 포스팅입니다.

지난 글에서 말씀 드렸듯이, 이번 글에서는 새롭게 추가된 Data Flow Rules에 대해서 소개 드리겠습니다.

새롭게 추가된 8개의 Data Flow 규칙들

일단, 새롭게 추가된 규칙 목록을 먼저 보도록 하겠습니다.

이 규칙들 중에서, CA2000을 제외하면 모두 Visual Studio Team System 2005에서 이미 지원했었던 규칙입니다. 그리고 사실 CA2000도 VSTS 2005에 없었다 뿐이지, FxCop 1.35버전에서는 있었구요. 하지만 이 규칙들은 FxCop 1.36과 Visual Studio Team System 2008에서는 빠져있습니다.

이 규칙들이 빠졌던 이유에 대해서는 아래 URL을 보시면 됩니다.

http://code.msdn.microsoft.com/codeanalysis/Release/ProjectReleases.aspx?ReleaseId=556

즉, FxCop 1.35와 VSTS 2005에 있었던 Analysis 엔진에 성능의 결함, 버그, 일관적이지 못한 분석 결과 등의 문제가 있어서, 그 엔진을 VSTS 2008과 FxCop 1.36에서는 완전히 없애 버린 것입니다.

하지만, 이번 Visual Studio 2010에서는 화려하게 복귀가 되었습니다. 

Phoenix Framework의 탑재

그게 가능했던 이유는 새롭게 탑재된 Phoenix Framework 덕분입니다. 피닉스 프레임워크는 향후 마이크로소프트 컴파일러 기술을 위한 새로운 코드 최적화/분석 프레임워크입니다. C++/CLI 기반으로 만들어진 피닉스 프레임워크는 컴파일러, 코드 최적화, 자동 코드 생성 등 여러 분야에 사용될 수 있는 프레임워크인데요. 자세한 정보는 아래 URL에서 보실 수가 있습니다.

http://research.microsoft.com/en-us/collaboration/focus/cs/phoenix.aspx

https://connect.microsoft.com/Phoenix

그러면 다음 글을 통해서, 새로운 Analysis Engine인 Phoenix 프레임워크에 대해서 더 자세히, 그리고 어떻게 우리가 사용할 수 있을지 알아보도록 하겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Architect Development 을 위하여 무엇을 해야 할가요?
아니 Architect Development 이란 영역은?

우리가 흔히 개발을 한다고 하면 보통 요구사항 분석, 설계, 개발, 테스트 및 디버깅, 배포를 끝으로 그 다음 유지보수를 합니다. 유지보수에서는 개발, 테스트 및 디버깅 재배포 등의 단계를 거치게 됩니다.
그렇다면 여기서 앞 부분은 요구사항 분석, 설계 부분은 유지보수에서 빠지는 것일까요?

답은 " 아닙니다 " 겠죠? 그렇다면 요구사항 분석, 설계 부분이 빠지는 이유는 개발이 완료되고 배포되어 사용자가 사용하고 있는 중에 문제가 오류가 발생하여 개발자 분들이 수정하고 다시 테스팅 및 디버깅 후 배포하는 것입니다. 프로그램이 사용중에 오류가 발생하지 않고 고객 또는 사용자가 새로운 기능을 요구하였을 경우에는 어떻게 할까요?

여기서 옛날에 했던 요구사항 분석, 설계 부분을 돌아보게 됩니다. 그러면, 제가 지금까지 보아온 회사 중에서는 설계가 잘되어 있고, 요구사항 분석도 잘 되어 있어 모든 것이 일사 천리로 일이 진행 된것을 볼 수 있었습니다. 그렇지 않은 회사를 보면 어떻게 될지는 이 글을 읽는 개발자 분들이 더 잘 아실거라 생각합니다. 그럼 아키텍쳐 개발은?

아키텍처란 용어는 영한 사전에서보면  일반적으로 "건축, 천축술, 천축 양식, 구조"라고 번역합니다. 그렇다면국어사전은? 기능 면에서 본 컴퓨터의 구성방식이라고 설명합니다.(네이버 국어사전 참조) 여기서 아키텍쳐란 구조, 구성이라는 용어로 한번 보겠습니다.

구조, 저희가 개발하는 시스템에 대한 정확인 요구사항에 맞는 분석과 이를 기반으로 정확한 구조, 구성이 된 설계가 있다면 어떨까요? 이 설계의 기본적인 구조는 Windows 플랫폼에 PHP 개발, 아니면 ASP.NET 개발등으로 예를 들어 보고, 기본적인 구조를 정확히 정의하고 이를 표현할 수 있으며, 많이 사용하는 방법으로 표시하여 개발자들과 협업, 의사 소통이 이루어 질 수 있다면 어떨까요?

전 이 해답을 Visual Studio Team System(VSTS) 에서 찾았다고 생각합니다. 제가 MS 쪽 제품 중에 VSTS를 좋아하는 이유 중에 바로 Architect Development이 가능하게 해준다는 것입니다. 다른 제품 쪽도 있고 저 역시 다른 사이트에서 많은 자료를 봅니다.(다른 사이트의 Meet the Experts등 여러 사이트가 있습니다. 단 영어 입니다 ㅠ.ㅠ)

옛날 VSTS는 업계가 많이 사용하는 UML를 지원하지 않고 다른 모델링 도구등을 이용한 설계를 할 수 있도록 했습니다. 기능은 매우 훌륭했지만... 많은 사용자가 이것을 사용했을까 하는 것입니다. 지금은?

VSTS 에서도 이제 UML도 지원한다..

그럼? 네 Visio 같은 도구로 그림을 그리는 것이 줄어들었다는 것입니다. 그리고 VSTS에 통합되므로써 개발자들과의 의사소통, 협업이 가능하다는 것이 매우 좋아졌다는 겁니다. 프로젝트에서 대부분 아키텍쳐는 무시되고 요구사항이 수시로 바뀌는 등등 매우 많은 일들이 생겨나는데 이것을 대응할 수 있다는 것입니다.
업계에서 많이 사용하는 UML은 학교에서 S/W를 전공한 사람은 모두 한번씩 배웠던 것이고, 이를 이용하여 개발자들과 협업을 통해 고객의 요구사항을 능동적으로 대처할 수 있고, 실제 설계에 반영할 수 있습니다.

이런 매우 좋아진 이 VSTS 2010에 대하여 이제 부터 제가 하나씩 하나씩 알아보고 여러 분들에게 소개를 하겠습니다. ^^ 다음 은 그럼?? VSTS 2010의 모델링 개발에 대하여 이야기 하겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

 

TDD and BDD via Mock of POWERUMC.zip

Moq.NET

Moq 는 "Mock-you" 또는 "Mock" 로 부른다고 합니다. Moq.NET 3.0 은 C# 3.0 과 .NET Framework 3.5 를 통해 Linq Expression Tree 와 Lambda Expression(람대 표현식) 으로 직관적이고 생산적이라고 합니다.

이전에 봤던 웹 사이트 로그인 사용자 스토리를 다시 봅시다. 단, 이 예제에서는 복잡성을 만족하는 항목을 삭제합니다.

웹 사이트의 로그인 사용자 스토리

• 사용자 아이디는 영문만 입력 가능하고 한글은 입력할 수 없다
• 사용자 아이디는 최소 3자리, 최대 10자리까지 입력가능하고 초과시 경고 메시지를 보여준다
• 사용자 비밀번호는 최소 5자리, 최대 20자리까지 입력 가능하고 초과시 경고 메시지를 보여준다

위의 사용자 스토리를 Mocking Framework 인 Moq.NET 을 이용하여 TDD와 BDD 형태로 테스트를 작성해 나갈 수 있습니다.

아래의 소스 코드는 Login 인터페이스를 정의한 코드입니다.

이제 Login 의 Behavior(행위) 측면에서 주도적인 개발을 하고자 합니다. BDD 이용하여 [그림1] 의 Clean up code 를 얻기 위한 목적이 아닙니다. 좀 더 TDD 에 가깝고, 디자인과 설계에 초점을 맞추고자 합니다.

위의 코드를 통해 Mocking Object 를 생성하도록 Mock<T> 생성자를 볼 수 있습니다. 바로 Mock<T> 를 통해 Mocking Object 를 생성합니다.

아래의 코드는 위의 로그인 사용자 스토리에서 입력되는 아이디/비밀번호의 유효성을 검사하도록 Mocking Object 를 설정합니다.

아래의 코드는 유효성을 통과한 아이디/비밀번호로 로그인을 시도하고 결과값을 리턴하는 Mocking Object 입니다.

자, 그럼 가상의 Mocking Object 를 통해 인터페이스만으로 로그인 시도를 해보도록 하겠습니다.

입력 변수 값에 따라 비록 Mocking Object 지만, 테스트 시나리오를 충분히 검증할 수 있습니다.

Id="aaa", pwd="aaa" 일 경우는 아래와 같은 결과가 나타나겠죠~?

Id="powerumc", pwd="aaaa" 일 경우는 아래와 같이 모든 테스트 시나리오를 통과한 결과입니다.

그럼, Microsoft Research 프로젝트의 일환인 Pex 를 이용하여 Mocking Object 를 Testing 해보겠습니다. Pex 테스트 프로젝트를 생성하고 아래의 PexMethod 를 만들었습니다.

아래는 테스트 결과입니다. 총 31개의 테스트 케이스 중에 통과되는 1개의 테스트를 확인할 수 있습니다.

자 어떻습니다~? 전혀 구현 코드를 구현하지 않았음에도 인터페이스를 통해 TDD-테스트 주도 개발이 가능합니다. BDD-행위 주도 개발을 통해 번거로운 TDD 의 Red, Green, Refector 의 유한반복 사이클 없이도, 실제 인터페이스의 디자인과 설계에 초점을 맞추어 테스트를 진행하였습니다.

단순히 BDD 가 최고야~ 라는 말은 아닙니다. 우리가 BDD 를 통해 TDD 를 좀 더 쉽고, 근접하게 접근할 수 있습니다. 그리고 코드의 구현이 전혀 없이 오직 디자인과 설계에 초점이 맞추어져 있다는 사실을 알면 됩니다. 바로 Moq.NET 은 Mocking Object 를 통해 TDD 와 BDD 개발을 통해 좀 더 품질 좋은 WhiteBox Testing 의 기대효과를 누릴 수 있습니다.

데이터베이스의 데이터를 조회하여 테스트한다고 할 때에도, 반드시 데이터베이스가 존재하지 않아도 됩니다. 가상의 데이터베이스 커넥션 객체를 만들어서 쓰면 됩니다. 쇼핑몰 사이트에서 결재 프로세스를 테스트해야 하나요? 그렇다면 가상의 객체를 통해 설계된 결재 프로세스가 합당한지 Mocking Object 를 통해 테스트를 하면 됩니다. 그 이후에는 잘 설계된 인터페이스를 구현하기만 하면 되겠죠?

이 외에도 WikiPedia 에 Mock Library 의 종류가 있네요. 아무튼 테스트와 Moq.NET 에 대한 내용은 여기까지 하는 것으로 마치도록 하렵니다.

참고 문헌

http://en.wikipedia.org/wiki/Mock-object
http://behaviour-driven.org/

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

TDD 는 그렇다고 치고, 이제는 BDD(Behavior-Driven Development-행위 주도 개발) 가 왠말이냐 -_-; 저 또한 Moq 에 생소한 나머지 여기까지 추적하게 되었습니다. 모두가 TDD 가 좋은 줄은 압니다. 종속적인 기능이나 코드가 정상적임을 증명하고 점진적으로 테스트 코드를 만듦으로써 자연스럽게 세부 설계를 생각하게 할 수 있습니다.

나에게 "TDD" 를 요구한다면 나에게 "시간"을 달라

어째든, BDD 는 소프트웨어 품질을 향상하기 위해 개발자간에 협력할 수 있는 Agile Software Development 기법입니다. BDD 의 목표는 TDD 를 수행하기 위한 것이며 TDD 의 접근법을 전환한 것입니다. TDD 의 딱딱한 어휘를 정리하고 설계나 디자인에 초점이 맞추어진 패러다임의 전환이라고 합니다. 그리하여 TDD 를 수행한다는 본질은 변하지 않지만, TDD 를 수행하기 위해 BDD 를 통해 행위 자체는 변할 수 있다는 것입니다.

더 자세한 내용은 아래의 Behavior-Driven Development 공식 사이트를 참고하십시오.

또한 Agile Software Development 에서 각 이터레이션(Iteration)에서 수행하게 될 사용자 스토리를 통해 기능이나 구현에 대한 스팩을 정의할 수 있습니다. 즉, 애자일의 사용자 스토리는 바로 테스트를 수행하는 테스트 시나리오로 이어지게 됩니다. 헌데, TDD 로만 수행되는 테스트 시나리오는 실제로 변화에 능동적으로 대처하지 못할 수 있는 경우도 존재합니다.

예를 들어, 설계자는 개발자에게 아래의 스팩이 만족하는 로그인 기능의 "사용자 스토리" 를 정의합니다.

웹 사이트의 로그인 사용자 스토리

• 사용자 아이디는 영문만 입력 가능하고 한글은 입력할 수 없다
• 사용자 아이디는 최소 3자리, 최대 10자리까지 입력가능하고 초과시 경고 메시지를 보여준다
• 사용자 비밀번호는 최소 5자리, 최대 20자리까지 입력 가능하고 초과시 경고 메시지를 보여준다
• 사용자 비밀번호는 복잡성 만족도를 우측에 색깔과 메시지로 보여준다

위의 사용자 스토리에 만족하도록 TDD 를 수행해야 하는데, TDD 를 수행하기 위해서는 반드시 스토리의 우선 순위대로 진행해야 다음의 테스트 코드를 작성할 수 있습니다. 그런데 여기에 엄청난 함정이 있을 수 도 있습니다.

• 초/중반의 우선순위의 사용자 스토리의 규모가 한 이터레이션의 주기와 맞먹는 경우라면 TDD 를 어떻게 수행할건가요?
• 또는, 로그인 시나리오(에피소드, 테마) 안에 고객의 쉽지 않은 요구사항이 추가되었다면 어떻게 할건가요?
  

예를 들면, 설계가 진행 도중 아래와 같은 요구 사항이 추가가 되었다고 가정해 봅시다.

• 로그인은 SSO(Single Sign On) 을 통해 로그인하며, SSO 중앙 서버를 통해 인증해야 합니다.

기가 막히군요. 아직 SSO 서버는 구축이 되지 않은 상태이고, 단일 시스템간에 명확한 프로토콜도 정의되지 않은 시점입니다. TDD 를 수행하기 위해 SSO 중앙 서버와 프로포콜이 구축되지 않는다면 더 이상 로그인과 관련된 작업은 진행할 수 없게 됩니다.

자! 바로 이런 경우 행위 주도 개발-BDD 가 빛을 발할 때입니다. BDD 의 행위 주도 개발은 인터페이스와 구현을 분리하고 인터페이스에 집중할 수 있습니다. 즉, 어떠한 구현 코드가 없이도 BDD 를 통해 인터페이스만으로 테스트나 코드를 통해 설계 작업을 진행할 수 있게 되는 것입니다.

구현 코드가 없이 인터페이스만으로 테스트를 진행한다니요? 이거 말장난 아닙니까? 아닙니다. 객체의 구현은 전혀 알 필요 없습니다. 단, 내부적인 테스트 시나리오를 알고 있는 것만으로 테스트를 진행하게 됨으로써, 인터페이스의 디자인이나 설계에 집중하게 됩니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이번에 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)

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

위 그림처럼 이번 Visual Studio Team System 2010에서는 Analyze(분석) 메뉴에 새로운 기능이 하나 더 추가되었습니다. 바로 Visualize Code Relationships 메뉴입니다. (아직 한글로는 어떻게 번역될 지 잘 모르겠네요)

이 기능은 제목 그대로 코드의 관계를 시각화해서 보여 줍니다. UML 다이어그램과도 조금 다르고, 모델링 용의 DSL 다이어그램과도 조금 다르긴 하지만, 꽤 괜찮은 그림을 보여줍니다.

그림을 한 번 보기 위해서, 아래와 같은 아주 간단한 Visual Studio 솔루션을 한 번 구성해봤습니다.

구조는 간단합니다. WebApplication1이 WebService1을 Web Reference를 해서 호출하고, 다시 WebService1은 ClassLibaray1을 내부적으로 Reference해서 호출하는, 아주 흔한 형태의 Application 구조입니다. 그리고 ClassLibrary1 내부에서 Class2는 Class1을 사용합니다.

이 구조가 어떻게 시각화 되는지 한 번 볼까요?

1. Visualize Call Dependency – By Assembly

오른쪽 옆의 버튼을 누르면, 내부로 펼쳐지면서, 내부에 들어있는 클래스도 보입니다.

2. Visualize Call Dependency – By Namespace

3. Visualize Call Dependency – By Class

프로젝트가 성숙하고 발전되면, 코드도 따라서 많아지면서 구조도 복잡해지기 마련입니다. 복잡도가 높아지면 높아질 수록 유용한 툴이 되지 않을까 싶습니다.

하지만, 지금 그림을 보시면 아시겠지만, WebApplication1이 Web Service1를 Web 참조를 하고 있습니다만 그림에는 그 참조 관계는 표시가 제대로 되질 않네요. 결국 직접적인 참조 외에는 다이어그램에서 보기가 힘든 것 같습니다. 쉽지 않겠지만, 그런 부분들도 표시할 수 있었더라면 정말 환상적이었을 텐데 하는 생각이 듭니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

지난 번 글에서 Visual Studio Team System 2010의 향상된 Unit Test 기능에 대해서 살펴 본 바가 있었습니다. 오늘 소개드릴 PEX는 Microsoft Research 그룹에서 개발한 Automated Whitebox Testing Framework 입니다. 꽤나 긴 정의입니다만, 간단히 말하자면 자동으로 코드를 분석해서 WhiteBox Unit Test를 만들어주는 Visual Studio Extension입니다.

Unit Test를 수행할 때에 대개 Code Coverage Test를 같이 수행하는 이유가 바로 우리가 작성한 Unit Test가 어느 정도 수준의 Whitebox Testing에 도달했는지를 알 수가 있기 때문입니다. 당연히 우리가 작성한 모든 코드에 대해서 완벽한 Whitebox Testing을 Unit Test를 통해서 수행했다면 Code Coverage Test의 결과는 100%가 되어야 합니다. 하지만, 실제로 Unit Test건 Manual Test Case건 Code Coverage Test결과가 100%에 도달하기는 참으로 힘듭니다. 일반적으로 80%정도를 목표로 하지만, 그 이하가 되는 경우가 대부분입니다. 그것은 복잡성의 문제이기도 하고, 비용 대비 효과의 문제이기도 합니다. 코드의 모든 경로를 통과하는 Unit Test를 작성하려면 엄청난 시간이 소요될 테니까요.

이 점이 PEX라는 제품이 나오게 된 배경이라고 할 수 있습니다. PEX는 Visual Studio의 코드를 분석해서, Input과 output 조합을 찾아서 자동으로 테스트 코드를 만들어 줍니다. 자동으로 생성된 테스트 코드이지만, 높은 Coverage를 보여 줍니다. PEX를 사용하면, Unit Test 작성에 들이는 수고를 상당히 줄일 수 있을 것 같습니다.

PEX 홈페이지는 http://research.microsoft.com/en-us/projects/pex/default.aspx 이며, 현재 Visual Studio Team System 2008과 2010에서 사용할 수 있다고 되어 있습니다. 즉, 현재 VSTS 2008을 쓰고 계시는 개발자 분이라면 다운로드 받아서 써 보실 수 있다는 의미입니다. 현재 정식 버전은 아니고 Pre-release 버전입니다. 그리고 Visual Studio 2008 Professional 버전을 위한 비 상업용 Academic 버전도 다운로드 받을 수 있습니다. 다운로드 링크는 http://research.microsoft.com/en-us/projects/pex/downloads.aspx 입니다.

이번 글은 개요이니까, PEX Tutorial에 나오는 간단한 샘플만 잠시 보도록 하겠습니다.

   1:  [PexMethod]

   2:  public void ParameterizedTest(int i)

   3:  {

   4:       if (i == 123)

   5:           throw new ArgumentException("i");

   6:  }

Integer 타입의 매개 변수를 받는 간단한 메소드입니다. 매개 변수가 123일 때에는 ArgumentException을 일으키는 딱 두 줄의 구현만 있을 뿐입니다. PexMethod Attribute는 이 메소드가 PEX Test method라는 것을 의미합니다. 이 메소드에 대고 마우스 오른쪽 클릭을 하게 되면 컨텍스트 메뉴에 다음과 같이 PEX 관련 메뉴들이 보이게 됩니다.

여기서 Run Pex Explorations를 선택하게 되면, PEX가 자동으로 코드를 분석해서 가능한 모든 매개 변수를 대입해 본 다음 그 결과를 바탕으로 아래처럼 결과를 보여주게 됩니다.

예상대로 123이라는 매개변수가 입력되었을 때에 ArgumentException이 발생한 것을 볼 수가 있습니다. 그리고 여기서 또 다시 마우스 오른쪽 컨텍스트 메뉴를 통해서 Go To를 선택하게 되면 실제 자동으로 생성된 테스트 코드를 아래 그림처럼 볼 수가 있습니다.

   1:  [TestMethod]

   2:  [PexGeneratedBy(typeof(HelloWorldTest))]

   3:  public void ParameterizedTest01()

   4:  {

   5:      this.ParameterizedTest(0);

   6:  }

   7:   

   8:  [TestMethod]

   9:  [PexGeneratedBy(typeof(HelloWorldTest))]

  10:  [PexRaisedException(typeof(ArgumentException))]

  11:  public void ParameterizedTest02()

  12:  {

  13:       this.ParameterizedTest(123);

  14:  }

간단한 샘플이긴 하지만, PEX의 강력한 자동 테스트 코드 생성 기능을 볼 수 있으셨을 거라고 생각합니다. 다음 포스팅에서는 PEX에 대해서 더 깊이 들어가 보겠습니다. 아 물론, Code Analysis에 대한 글들도 계속 올릴 예정입니다. 읽어주셔서 감사합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.