출처: http://blog.naver.com/infopub?Redirect=Log&logNo=100088917941
당연히, 이런 혼란을 극복하는 것은 이런 일이 아예 일어나지 않도록 하는 것이다. 코드가 조각으로 나누어져 빌드되고 테스트가 완료된 다음에 이들이 모여 점점 크게 된다면, 이들이 어우러져 전체 제품이 되는 것은 놀라운 일이 아니다([그림 7.3] 참고).
 [그림 7.3] 각각의 조각들을 따로따로 빌드하고 테스트한 다음에, 이들을 합쳐서 다시 테스트한다.
가장 낮은 수준에서 일어나는 테스트를 단위 테스트(unit testing) 또는 모듈 테스트(module testing)라고 한다. 단위들을 각각 테스트하여 저수준의 버그들을 발견하여 수정하고 나면, 이들을 한데 모아 모듈 그룹 단위로 통합 테스트를 시행한다. 이런 식의 테스트는 더 많은 조각들을 모아서 한 번에 전체 제품에 대한 테스트를 할 수 있을 때까지 계속된다. 전체 제품에 대한 통합 테스트를 시스템 테스트(system testing)라고 한다.
이런 테스트 전략을 사용하는 것이 버그를 찾아내기 훨씬 더 쉽다. 모듈 단계에서 발견된 문제는 그 모듈 내에 있는 것임에 틀림없으며, 통합된 여러 모듈을 테스트하는 단계에서 발견된 버그는 모듈간의 상호작용에서 발견된 것이 확실하다. 물론 예외도 있지만, 대개는, 이렇게 하는 것이 모든 것을 한꺼번에 테스트하는 것보다는 훨씬 효과적이다.
이렇게 점진적인 테스트를 하는 접근 방법에는 상향식(bottom-up)과 하향식(top-down)이 있다. 상향식 테스트에서([그림 7.4] 참고), 여러분은 이른바 테스트 드라이버(test driver)라고 불리는 모듈을 만드는데, 테스트하려는 모듈을 실행시키는 역할을 대신하게 된다. 테스트 드라이버는 나중에 진짜 모듈이 하는 것과 완전히 같은 식으로 결합된다. 이 테스트 드라이버는 테스트하려는 모듈에 테스트 데이터를 넣어주고 결과를 받아온 다음, 결과가 옳은지를 검사하게 된다. 이런 방법을 쓰면, 더 높은 수준으로는 가능하지 않은 모든 형태와 값의 데이터를 다 넣어볼 수 있어서 매우 철저한 테스트가 가능해진다.
 [그림 7.4] 테스트 드라이버는 실제 소프트웨어를 대신하여 저수준 모듈에 대해 더 효율적인 테스트를 할 수 있다.
하향식(top-down) 테스트는 빅뱅 테스트를 작게 해놓은 것처럼 보일지도 모르겠다. 하여간에, 고수준의 소프트웨어가 완성된 다음에 저수준의 모듈들을 테스트하기는 이미 늦지 않을까? 실제로, 꼭 그렇지만도 않다. [그림 7.5]를 보라. 이런 상황에서는 저수준 인터페이스 모듈이 전자 온도계로부터 온도 정보를 수집하는 용도로 사용되었다. 디스플레이 모듈은 인터페이스 바로 위에 위치하면서 인터페이스에서 읽어온 데이터를 사용자가 볼 수 있도록 표시한다. 맨 위에 있는 디스플레이 모듈을 테스트하려면, 화염을 내뿜고 물과 얼음에 꽁꽁 얼리는 등 센서의 온도를 다양하게 변화시켜 데이터가 전송되도록 해야 할지도 모른다.  [그림 7.5] 테스터가 작성한 모듈이 테스트 중인 모듈에 데이터를 보낸다.
온도 디스플레이 모듈을 테스트함에 있어서, 온도계의 온도 자체를 변화시키는 대신에, 여러분은 이른바 "스텁"이라고 불리는
조그만 코드를 작성하는데, 이는 진짜 인터페이스 모듈처럼 동작하며 파일에서 "가짜" 온도 값을 읽어서 디스플레이 모듈에 보내는
역할을 한다. 디스플레이 모듈은 진짜 온도계 인터페이스 모듈에서 직접 읽는 것과 마찬가지로 데이터를 읽어서 온도를 표시하게
된다. 디스플레이 모듈은 읽어들인 온도 값이 진짜 인터페이스 모듈에서 온 것인지, 가짜 코드에서 온 것인지를 구분하지 못한다.
이러한 테스트 스텁 구성을 활용하면, 여러 가지 테스트 값을 넣어봄으로써 디스플레이 모듈이 잘 동작하는지를 빠르게 알아볼 수
있다.
 |
