역시나 MS Pattern & Practice 팀(이하 PP팀)은 나에게 또 하나의 두통거리를 던져줬다.
처음 NUnit를 사용하기 전에 사전조사를 했었다. 이런저런 관련문서를 읽어보고, 약간의 테스트를 마친 후에 나는 NUnit 코드는 테스트 대상 코드와 분리하는 편이 낫다고 판단했다. 이를테면 다음과 같이 프로젝트를 나누는 것이다.
-
대상 코드를 포함하는 프로젝트 이름: Microsoft.ThisIsSource
-
NUnit 코드를 포함하는 프로젝트 이름: Microsoft.ThisisSource.Tests
이렇게 구분하면 소스와 테스트 코드가 분리되기 떄문에 관리하기 편하다. 별다른 설정없이 대상 프로젝트에서는 종전처럼 프로그래밍을 하면 된다. 또한 테스트를 위해 .config 파일을 추가해야 할 경우가 있는데, 이 설정 파일도 테스트 프로젝트에 넣으면 된다. (분리하지 않으면 어떤 문제가 발생하는지는 뒤에서 언급하겠다.)
여러 블로거(적어도 내가 방문한 블로그의 주인)들이 위와 같은 방식을 추천했다. 그러나 PP팀은 전혀 다른 방식으로 테스트 코드를 관리했다. 즉 프로젝트를 나누지 않고 하나의 프로젝트에 대상 코드와 소스 코드를 합친 것이다. 물론 하위 폴더 Tests에 테스트 코드를 저장하여 어느 정도 분리하기는 했다. 그리고 전처리기 지시문 #if를 사용하여 Unit Test를 해야 할 때와 그렇지 않을 때(아마도 Release할 때)를 구분하도록 했다.
#if UNIT_TESTS
using System.Collections;
using System.Threading;
namespace Microsoft.Practices.EnterpriseLibrary.Common.Tests
{
public abstract class ThreadStressFixtureBase
{
}
}
#endif UNIT_TESTS 이런 식으로 구성하면 빌드할 때 경우에 따라 UNIT_TESTS를 지정하거나 해제하거나 해야 한다. 일반적으로 빌드 구성을 자주 바꾸는 것은 아니므로 이것은 그다지 문제되지 않을 수 있다.
결론
글을 쓰다 말고, 그 동안 이런저런 생각을 많이 해봤다. 분리하지 않는 경우에 있을 수 있는 문제점은 거의 관리 상의 문제들이다. 하지만 분리하지 않는다고 해서 크게 문제될 사항은 없는 것 같다. .config 파일을 어디에 둘 것인가 하는 문제가 마음에 걸리기는 하다. 프로젝트에 TestConfigurations라는 폴더를 하나 추가하고 그곳에 놓으면, 대상코드와 섞이는 일은 피할 수 있을 것 같다. ‘빌드 전 이벤트’에서 해당 .config 파일을 bin/debug 또는 bin/release 폴더에 복사하도록 하면 될 것이다.
단지 합치는 경우에는 그렇지 않은 경우보다 해야 할 일이 많을 것이다. (경험 상)
— 블로그 이전하기 전 코멘트
앤시스: 의외네요. PP팀의 방식은… ^^a 2005/03/18 20:14
쥐똥: 제 생각엔 프로젝트에 포함시키는 것이 나쁘지 않을 것 같습니다. 자바관점입니다. 자바 책이지만 TDDBE를 보면 그렇고, PP책의 start kit 인 cvs 등을 보아도 소스 관리차원의 대승론인가 싶습니다. 물론 님꼐서 말하는 소승론(제가 그냥 부쳐본 용어)도 분명 남을 이유가 있겠습니다. 2005/03/22 10:29
