Yagur의 Juggling

작성자: yagur Rev : 1

 모의 객체(Mock Object)

  프레임 워크와 같은것은 테스트 도구이지만 도구로 할수 있는 테스트 커버리지는 제한적이다. 그 제한 커버리지를 넓히것엔 여러 패턴과 방법이 동원된다. 그리고 이들은 결과물의 완성도를 높히는데 필요하다. 많은 테스트 패턴과 방법들은 모의 객체Mock Object를 동반 하는 경우가 많다. 그 중 BMW란 자동차 생산 업체는 모의 객체를 훌륭히 활용하고 있다.
  자동차를 고르는 기준은 많이 있다. 주행능력, 승차감, 디자인과 같은 것들이다. 이들 외에도 우리는 안전성을 본다. 사고시 차의 상태변화와 운전사를 포함한 탑승자의 안전상태를 중요하게 여기게 된것이다. 그럴수 밖에 없는 것이 자동차 사고로 죽는 사람의 숫자는 상상을 초월하기 때문이다. 이런 문제점을 받아들인 장인들의 제품(차)들은 견고함과 사고 대처 능력이 매우 뛰어나다고 알려져있다. 단지 소문만으로 저런 명성을 얻기는 힘들다. 저들은 모의 테스트라는 것을 통해 그 능력을 입증하고 있다.


  저들은 따로 차량 안전 센터에서 다중 충돌 테스트를 한다. 완성된 차량에 여러 방향에서 차량 충돌을 가하는데 모의 부품이 어디에 있는지 반문하는 분들도 계실것이다. 하지만 다시 본다면 모의 객체는 존재한다.
  테스트의 목적은 탑승자의 안전이다. 하지만 어느 회사도 실제 사람을 차량 안전 테스트용으로 쓸수 없을 것이다. 여기서 그들(자동차 생산 벤더)이 고안해낸 것은 모의 객체인 차량 충돌 인형(crash dummy)이다.


  크래쉬 더미는 사람과 비슷한 모양과 관절 구조를 지니고 있다. 그리하여 충돌시 어느 부위에 어떤량의 충격을 어떤 형태로 받는지 시험해보기 좋게 설계되어있다. 이런 형태를 가진 개체의 객체를 모의 객체라 하며, 소프트웨어와 하드웨어를 구분하지 않고 널리 사용되고 있다.
  특정 부분의 내구성이나 동작을 보기 위해 시스템 전체를 매번 테스트 하는것은 비용이 많이 소모된다. 그리 하여 특정 부분을 분리해내고 모의 환경을 조성해 테스트를 한다. 이럴 경우 비용은 매우 감소되며, 좀더 많은 횟수의 정밀한 테스트를 할수 있게 된다. 또 사용된 모의 환경과 객체는 개선된 제품의 테스트를 위해 재사용 될수 있으므로 일석이조이다.


  일석삼조가 될수도 있다. 모의 객체에 하나의 제품의 의미를 둘수있는데, 이는 모의 객체 역시 제품 테스트 과정에서 진화하기 때문이다. 모의 객체가 재사용 가능한 하나의 제품이 되는것이다. 예를 들면 충돌 테스트 더미와 같을것이다. 처음엔 관절도 거의 없고, 센서도 몇개 없었을 것이다. 허나 충돌 테스트 방향이 많아지고, 사고로 인한 사고 부위가 다양히 들어남에 따라 관절도 늘고, 충돌시 충격량을 체크하기 위한 센서도 늘어났을 것이다.
  좌측의 사진은 크래쉬 더미(Mock Object)의 진화형태이다. 갈비 뼈까지 재현해 내고있다. 저 정도 모의 객체라면 상품적 가치도 있을것으로 보인다. 실제 국제 크래쉬 더미로 쓰인다고 한다.

그리고 우린 모의 객체의 활용의 실례를 "6.테스트 의존성의 함정"에 있는 Self Shunt에서 찾아 볼수 있었다.


 모의 환경(Mock Environment)

  소프트웨어에서 모의 객체는 여러 방면으로 쓰일수 있다. 그중 하나는 모의 객체가 모의 환경으로서의 역활을 하는 경우이다. 모의 환경으로서의 한 예는 디스크 입출력을 예로 들수 있다. 디스크 입출력 환경을 모의 객체로 지정하고, 테스트 시에는 메모리에 입출력을 진행하여 테스트 속도를 높힐수 있다. 그리고 입출력 내용도 쉽게 확인할수 있다.
  물론 물리 디스크와 환경이 같지 않으므로 특정 퍼포먼스에 관련된 테스트는 실제 디스크에 입출력을 행하여야 정확한 결과를 얻을수 있다. 하지만 기록 내용 확인 차원과 같은 테스트는 메모리에 기록함으로서 테스트 수행 시간을 단축시킬수 있다. 또 디스크 공간이 부족한 경우를 시뮬레이션 시키거나, 강제로 입출력의 실패를 모의 시험할때 쓸수 있다.
  이런 모의 환경 객체들은 하나의 단위 테스트 외에도 여러 다른 테스트에 재사용 될 수 있으며, 경우에 따라 상품의 가치를 지닐수도 있다. 그 예로는 Compuware의 Boundschecker와 같은 메모리 누수 진단 도구를 들수 있다.
  Compuware의 Devpartner 바운즈체커는 메모리의 생성, 해제의 환경을 모의로 조성 함(후킹?)으로서 어디서 메모리 누수가 일어나는지 리포트 해주는 툴이다. 실행 환경중 메모리 관련 부분을 후킹하고 오버라이드 함으로서 사용자의 '메모리 누수에 관련된 스트레스 테스트 환경'을 훌륭히 조성해준다. 물론 사용자가 별도로 메모리 관련 오퍼레이터나 함수를 오버라이드해 테스트 해볼수도 있다. 하지만 좀더 전문화된 테스트환경을 조성하기 위해선 바운즈 체커를 고려해볼수도 있다. 하지만 $1800 란 가격은 IDE의 애드인치고는 비싼편이다. 단 이같은 툴을 만들기 위해 경력의 프로그래머를 한달 쓴다 해도 더 좋은 기능의 툴이 나오기를 기대하긴 힘들다.