테스트 주도 개발: (6) UI 와 기능이 붙어있는 모듈을 제작하는 습관을 버려야한다.

UI와 기능이 붙어 있다는 것은 당연한 것 아닌가라고 생각할 수 있다. 이것은 UI를 프로그래밍을 시작할 때, 보이는 것에 너무 집착한 나머지 잘못 들인 습관 때문인데, 전통적으로 보이는 것과 데이터는 분리되는 것이라 가르쳐 왔지만, 보이는 것에 대한 것에도 두 계층을 두는 것에는 신경을 못쓰기 마련이다.

MFC를 생각해보라 당신은 MFC의 수많은 윈도우 개체에 대한 클래스를 보고 "많다.."라고 생각했을 수 있다. 그리고, 능숙하게 혹은 샘플을 봐가면서 정도로 그것들을 사용해 보았을 터이다. 그렇게 해서 나온 최종 산출물은 MFC 자체와 당신이 직접 만든 코드가 분리되어 화면 그리기를 완성한다. MFC 소스가 있긴하지만 그것을 수정하지는 않지않나?

웹프로그래밍에 가면 사뭇달라진다. ASP나 PHP등은 MFC 같은 다양한 포맷을 지원하지 않는다. 아니 할 수도 없다. 너무 빨리 변하기 때문에 정형화된 컴포넌트라는 것은 금새 유행에 뒤떨어지고, 또 최종 사용자의 입맛에 맞지 않는 것이 될 것이기 때문이다.

그러나 요즘의 추세는 모든 제품이 웹기반으로 사용자 인터페이스를 만들고, AJAX등이 나오면서 스크립트 기반 화면 랜더러가 많이 나타나게 되었다. 스크립트가 클라이언트에 있든, 서버에 있든 MFC와 같은 자주 쓰는 형식의 웹 컴포넌트를 만들어 사용하는 것은 아주 좋은 습관이다.

그렇게 하는 것이 UI 테스트에 대한 케이스를 줄여줄 수 있고, 견고해질 수 있는 것이다. UI 테스트를 위해서는 고가의 UI 동작 재생기 소프트웨어를 사용해야하는데, 이는 개발자와 테스터간 대화가 전혀 없을 때를 가정하지 않는한 작은 프로그램에서는 그다지 필요없다고 생각된다.

UI 하부 엔진을 개발하는 쪽에서는 테스트를 위한 함수를 만들어 마치 사용자가 마우스나 키보드를 눌러서 데이터를 전달 받는 수준을 정의하면 그것이 웹폼이나 Win 32 UI 폼 혹은 X window UI 폼에서 그 함수를 최종적으로 호출하는 방식으로 동작하게되면 테스트하는데 자동화가 쉬워질 수 있다.

물론 아주 최전방의 테스트는 불가는한 부분도 있겠지만, 값의 레인지 테스트나 값의 포맷 테스트 등 가능해지는 부분이 많아지는 것을 고려하면, 그러한 설계 기반의 구현은 아주 도움이 된다.

테스트를 어떻게 할지를 생각해서 UI를 계층을 둔다는 것은 모듈화에 대한 기준이 될 수 있으며, 자동화된 UI 테스트에 대해 비용을 절감하는 중요한 요소가 된다.