Visual Studio 2005에서 가장 획기적인 기능으로 표현되었던 것들 중 하나는 Object Test Bench라고 불리는 창이다. 사실 이것은 수동적인 의미이기는 하나 디버깅과 단위 테스팅에 대한 또 하나의 방법으로 충분한 가치가 있다. 하지만 이 Object Test Bench와 짝이 잘 맞는 또 하나의 옛 파트너가 있다는 사실을 사람들은 잘 모르는듯 하다. Visual C++의 어셈블리 코드/메모리 상태 등을 조회함은 물론 Visual Basic 6.0 시절부터 인터프리팅 언어이기 때문에 지원해왔던 간단한 커맨드 라인까지 다양한 모습으로 우리에게 선을 보여왔던 '직접 실행 창'을 아는가? 오늘 이 글에서는 '직접 실행 창'이 Visual Studio 2005에서 어떻게 유용하게 쓰일 수 있는지를 보고자 한다. (닷넷 프레임워크 밖의 영역에 대해서는 다루지 않는 글임을 주지하기 바란다.)
이 직접 실행 창이 가지는 의미는 실로 크다. 직접 실행 창은 꼭 디버거가 돌고 있는 상태가 아니라도 닷넷 프로젝트나 닷넷 솔루션이 열려있는 시점이라면 언제나 사용이 가능하다는 것이 중요하다. 또한, 직접 실행 창의 내용이 정말 실행이 되는가 역시 문제일텐데, 이것을 어떻게 보증할까? 그렇다. 체크섬을 비교, 언제곧 내용이 바뀌면 스스로 컴파일러를 호출하여 직접 실행 창의 결과가 유효할 수 있도록 맞춘다. 코드 체크섬의 생성에 관해서 궁금하다면 C# 2.0의 새로운 지시자 기호인 #pragma를 참조하라.
직접 실행 창이 확실히 동작할 것이라는 점에 대해서는 직접 다루어보면 안다. 그렇다면 직접 실행 창에다가 대고 뭐라고 이야기를 해야 할까? 의외로 간단하다. 현재 프로젝트에서 사용하는 언어를 가지고 대화를 시작하면 된다. (컴파일 언어가 갑자기 인터프리팅 언어가 되버린다는게 달갑지 않을 수도 있지만 참고 해보기 바란다.
몇 가지 예를 들어보기로 하겠다. 여기서 사용하는 언어는 C#이 되겠다. (사실 C#에 대해서 전혀 모르는 개발자라도 냉큼 이해하기 쉬울정도로 극명한 구문이다.
* 특정 형식에 대한 정보 보기: 특정 형식의 상수, 정적 필드, 정적 프로퍼티, 부모 형식을 확인할 수 있는데 네임스페이스 이름을 포함하여 형식 이름을 써주면 대강의 정보를 나열해준다. 인터페이스의 경우 이런 정보를 명시적으로 출력해주지는 않는다. 만약 제네릭 기반의 형식이라면 형식 인수를 기입해주어야 한다. (형식 인수에 대해서도 네임스페이스 이름이 필요하다. 이런 면은 꽤 거추장스럽다.
System.Console
System.Windows.Forms.Form
System.Text.StringBuilder
* 특정 형식에 대한 인스턴스 생성하기: 역시 이것이 핵심이다. 하지만 이렇게 생성된 인스턴스를 어떻게 사용할 것인가? 그것이 바로 Object Test Bench가 되겠다. (물론 이름을 잘 알고 있다면 직접 실행 창에서 매개 변수로 전달하는 등의 일은 얼마든지 가능하다.)
다음의 스크린 샷을 참고하기 바란다. (스트링을 더하고 이것을 직접 실행 창 콘솔에 출력하는 방법까지 같이 설명하고 있다. System.Diagnostics.Debug 클래스의 WriteLine이라는 정적 메서드는 이럴 때 사용한다.)
당신의 의견을 작성해 주세요.