실용주의 프로그래머를 위한 단위 테스트 with JUnit

Toggle Space Navigation Tree
Space Map

철저한 단위 테스트로 우리가 작성한 코드에 생명을 불어넣자.

Unable to render embedded object: File (200411020003.gif) not found.
URL : http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200411020003
원서 : Pragmatic Unit Testing In Java With JUnit (The Pragmatic Starter Kit - Volume II)
저자 : Andrew Hunt , David Thomas
출판사 : Insight (인사이트)
번역자 : 이용원 , 김정민

프로젝트가 거의 막바지에 다다른 상태이다. 지난 9개월 동안 많은 개발자들이 고생 고생한 끝에 고객이 요청하는 대부분의 요구사항을 수용하면서 프로젝트를 진행한 끝에 프로젝트는 성공적으로 끝나가는 것처럼 보였다. 그러나 아니나 다를까 프로젝트의 막바지에 고객의 요구사항이 바뀐다. 특히 국내에서 수행하는 대부분의 프로젝트에서 요구사항의 변경은 빈번하게 발생한다. 프로젝트의 끝나는 시점까지 요구사항이 바뀌는 것을 당연하게 생각하는 것이 국내 대부분의 고객들 사고 방식이다. 고객들이 요구하는 이 같은 작은 요구사항의 변경이 성공적으로 끌날 수 있었던 프로젝트를 실패하도록 만드는 경우를 종종 본다. 그 이유는 뭘까..?

고객들 대부분의 사고방식은 작은 기능 한가지를 변경하는 것을 그리 대수롭지 않게 생각하는 경향이 있다. 그러나 UI상으로 보기에는 작은 기능인 것처럼 보이지만 기능상의 변경으로 인해 뒤따르는 후속 작업을 아는 개발자들의 입장에서는 상당한 업무 부담이 될 수도 있다. 고객이 처음 요구분석할 때의 요구사항 중 한가지를 프로젝트 후반에 변경했을 경우 뒤따르는 작업은 다음과 같다.

  • 변경된 기능에 따른 구현 작업을 해야한다.
  • 변경된 기능과 관련된 모든 기능들을 처음부터 다시 테스트해야한다.
  • 변경된 기능과 관련된 문서를 수정해야한다.

흔히들 고객들은 제일 첫번째에 해당하는 기능 구현 작업만 완료하면 될 것으로 생각하지만 실 프로젝트에서는 그렇지 않다. 각각의 기능들이 서로 연관관계를 가지고 있기 때문에 하나의 기능이 변경되었을 경우 관련된 모든 기능들을 테스트해야한다. 기능에 따라 정도의 차이는 있겠지만, 위 세가지 항목 중에서 가장 많은 시간을 요하는 것은 테스트이다. 테스트를 진행하기 위해서는 관련된 모든 기능들을 알고 있어야 하며, 과거에 진행했던 모든 테스트를 다시 한번 진행해야한다. 이 같은 경우가 한 두번 있는 경우에는 큰 문제가 없겠지만 빈번하게 발생할 경우 똑같은 테스트를 수십번(경우에 따라서는 수백번)씩 행해지는 경우가 대부분이다. 그러나 테스트하는 작업이 귀찮아서 테스트를 소홀히 했을 경우 고객에게 해당 기능들을 시현할 때 다른 기능들이 되지 않아서 낭패를 보는 경우가 많다.

만약 테스트를 자동화하는 것이 가능하다면 위와 같은 반복 작업에 소요되는 시간을 급격하게 줄여줄 수 있을 것으며, 반복적으로 테스트할 시간에 더 중요한 비지니스 로직을 구현하거나 자신간의 여가시간을 가질 수도 있을 것이다. 이 책은 이 같은 반복적인 테스트의 한계점을 극복하기 위하여 Junit이라는 프레임워크를 이용하여 테스트를 자동화할 수 있는 방법에 대하여 다루고 있다. 많은 사람들이 테스트는 귀찮고 짜증나는 작업이라고 치부해버리지만 이 책은 테스트를 프로젝트 성공에 있어서 가장 중요한 요소로 꼽고 있다. 자동화된 테스트 코드를 가질 경우 자신이 개발한 코드에 대하여 자신감을 가질 수 있다. 저 또한 프로젝트를 진행하면서 유지보수가 어렵거나 버그가 상존할 것으로 생각되는 코드이지만 일단 잘 돌아가는 코드이기 때문에 그냥 덮어 버리는 경우가 많다. 그러나 꼭 이러한 코드에서 문제가 발생하게 되며, 다른 기능을 구현하면서도 의심이 가는 코드에 대해서 걱정하는 경우가 종종 있다. 이런 경험이 거듭될 수록 테스트가 얼마나 중요한 요소인지를 인식할 수 있다. 그러나 국내의 프로젝트 상황에서 충분한 테스트를 진행하기 힘든 것이 현실이고, 테스트는 프로젝트가 거의 끝나가는 마지막 부분에 의례적으로 작성하는 것으로 생각하다보니 시간이 없다는 핑계로 테스트의 중요성을 망각하는 경우가 종종 있다.

이 책에서는 소스 코드를 작성하기에 앞서 테스트 코드를 먼저 만들 것을 강조하고 있다. 새로운 소스 코드는 테스트가 존재하는 상황에서만 추가해야 한다고 말한다. 기존의 개발 방식에 젖어 있는 우리들로서는 어찌보면 말도 안되는 말장난처럼 들릴 수도 있다. 그러나 이 책의 내용은 단지 말장난이 아니다. 그 동안 수십년에 걸쳐서 프로젝트를 진행하면서 실패한 경험들을 바탕으로 테스트가 얼마나 중요한 부분인지를 인식하고 있는 것이다. 국내의 대부분의 프로젝트에서는 아직도 과거 방법론들만을 고집하고 있다. 새로운 것을 받아들이는 것을 꺼려하는 문화적인 부분과 하청 구조에 의한 구조적인 부분들도 새로운 개발 방법이나 새로운 접근을 거부하게 만들고 있다. 그러나 지금까지 진행해왔던 프로젝트들에서 실패한 프로젝트들이 많았다면 실패한 프로젝트들의 요인을 분석해보고 해결 방법을 찾는 것이 중요하다고 생각한다. 실패 요인중에 중요한 위치에 테스트의 부재가 자리잡고 있을 것이다. 철저한 테스트를 여러분의 프로젝트를 성공으로 이끌 것이다.

이 책은 단지 Junit 프레임워크를 이용하여 철저한 테스트를 어떻게 수행할지에 대하여 이야기하고 있다. 이 책이 다루고 있는 내용들을 여러분의 프로젝트 상황에 맞도록 Customizing해서 사용하는 몫은 여러분들에게 달려 있다. 그러나 여러분들이 테스트의 중요성을 인식하고 구체적으로 실행해보고 싶다면 이 책은 개발자 각각에게 좋은 가이드 역할을 해줄 것이다. 이 책에 나오는 예제들과 연습 문제들을 하나씩 해결해 나가면서 여러분들이 테스트의 중요성을 느낄 수 있는 기회가 되었으면 하는 바램이다.

국내 IT 서비스에 대한 고객들의 인식이 바뀌기에는 아직까지 많은 시간을 요할 것으로 생각한다. 고객들이 변하지 않는다면 고객들을 변화시키기 위한 노력도 해야겠지만, 더불어 현재 발생하고 있는 문제점들을 인식하고 해결방법을 찾는 노력도 같이 해야 할 것이다. 이 책에서 다루고 있는 내용 또한 다양한 고객들의 요구사항 변경에 대응하기 위해서 우리들이 가질 수 있는 또 하나의 방법으로 생각된다.

지금까지 우리들이 개발한 많은 코드들에 대하여 자부심을 가질 수 있으며, 사장되어가는 코드가 아닌 생명을 가진 코드를 만들 수 있는 그 날이 오기를 바래본다.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.